On Mon, Oct 14, 2013 at 4:29 AM, Jiang Xin wrote:
> In test cases for relative_path, path with one leading character
> (such as /a, /x) may be recogonized as "a:/" or "x:/" if there is
> such DOS drive on MSYS platform. Use an umambigous leading path
> "/foo" instead.
>
> Also change two leading
Matthieu Moy wrote:
> Jens Lehmann writes:
>> static struct lock_file lock_file;
>> +#define SUBMODULE_WITH_GITDIR ((const char *)1)
>
> I don't like very much hardcoded addresses like this. Are you 100% sure
> address 1 will never be returned by xstrdup on any platform? The risk is
> small if n
On Mon, Oct 14, 2013 at 12:01 AM, Jonathan Nieder wrote:
> Hi,
>
> David Aguilar wrote:
>> Felipe Contreras wrote:
>
>>> Virtually all packaging guidelines would prefer 1.8.4~rc1, over
>>> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
>>>
>>> In particular, the only packaging we
Daniel Stenberg wrote:
> On Sat, 12 Oct 2013, Eric Wong wrote:
>
> >This is a follow up to commit
> >e47a8583a20256851e7fc882233e3bd5bf33dc6e (enable SO_KEEPALIVE for
> >connected TCP sockets).
>
> Just keep in mind that TCP keep-alive is enabled in awkwardly many
> different ways on different s
Thomas Rast wrote:
> Junio C Hamano writes:
>> Thomas Rast writes:
>>> Existing gitk chokes on 'gitk -S foo', but works with 'git -Sfoo'.
>>
>> I somehow thought that we encourage the "stuck/sticked" form, to
>> reduce things the users need to remember to cope better with options
>> with optiona
Hi,
David Aguilar wrote:
> Felipe Contreras wrote:
>> Virtually all packaging guidelines would prefer 1.8.4~rc1, over
>> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
>>
>> In particular, the only packaging we provide, git.spec, generates a
>> wrong version, because git-1.8.4 <
On Sun, Oct 13, 2013 at 4:56 PM, David Aguilar wrote:
> On Sat, Oct 12, 2013 at 12:07 AM, Felipe Contreras
> wrote:
>> Virtually all packaging guidelines would prefer 1.8.4~rc1, over
>> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
>>
>> In particular, the only packaging we provi
Using a relative_path as git_dir first appears in v1.5.6-1-g044bbbc.
It will make git_dir shorter only if git_dir is inside work_tree,
and this will increase performance. But my last refactor effort on
relative_path function (commit v1.8.3-rc2-12-ge02ca72) changed that.
Always use relative_path as
Tvangeste found that the "relative_path" function could not work
properly on Windows if "in" and "prefix" have DOS drive prefix
(such as "C:/windows"). ($gmane/234434)
E.g., When execute: test-path-utils relative_path "C:/a/b" "D:/x/y",
should return "C:/a/b", but returns "../../C:/a/b", which is
In test cases for relative_path, path with one leading character
(such as /a, /x) may be recogonized as "a:/" or "x:/" if there is
such DOS drive on MSYS platform. Use an umambigous leading path
"/foo" instead.
Also change two leading slashes (//) to three leading slashes (///),
otherwize it will
Update since v4:
* Update commit logs with the help from Sebastian Schuberth:
s/MINGW/MSYS/i
s/dos-driver-prefix/dos-drive-prefix/
Jiang Xin (3):
test: use unambigous leading path (/foo) for MSYS
relative_path should honor dos-drive-prefix
Use simpler relative_path when set_git_dir
2013/10/11 Sebastian Schuberth :
>> In test cases for relative_path, path with one leading character
>> (such as /a, /x) may be recogonized as "a:/" or "x:/" if there is
>> such DOS drive on MINGW platform. Use an umambigous leading path
>> "/foo" instead.
>>
>> Also change two leading slashes (//)
Stefan Saasen wrote:
> Signed-off-by: Stefan Saasen
> Acked-by: David Aguilar
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Oct 12, 2013 at 12:07 AM, Felipe Contreras
wrote:
> Virtually all packaging guidelines would prefer 1.8.4~rc1, over
> 1.8.4.rc1 or 1.8.4-rc1, so it makes sense to use that instead.
>
> In particular, the only packaging we provide, git.spec, generates a
> wrong version, because git-1.8.4 <
On Sun, Oct 13, 2013 at 08:42:40PM +, brian m. carlson wrote:
> If I'm going to be adding an option to a command, should I update the
> documentation in the same commit or in a separate commit?
I would say the same commit, where it can help a reviewer see the code
change in the context of the
If I'm going to be adding an option to a command, should I update the
documentation in the same commit or in a separate commit?
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 91
Hi,
Yoshioka Tsuneo writes:
> "git diff -M --stat" can detect rename and show renamed file name like
> "foofoofoo => barbarbar", but if destination filename is long the line
> is shortened like "...barbarbar" so there is no way to know whether the
> file is renamed or existed in the source commi
On 05.10.13 21:48, Torsten Bögershausen wrote:
> On 2013-10-03 03.31, Jeff King wrote:
>>
>> http://article.gmane.org/gmane.comp.version-control.git/235473
What do we think about extending the test a little bit:
git diff 771cf1dab9303bab3c8198b8b6 -- t5602-clone-remote-exec.sh
diff --git a/t/
Am 13.10.2013 17:05, schrieb Matthieu Moy:
> Jens Lehmann writes:
>
>> static struct lock_file lock_file;
>> +#define SUBMODULE_WITH_GITDIR ((const char *)1)
>
> I don't like very much hardcoded addresses like this. Are you 100% sure
> address 1 will never be returned by xstrdup on any platform
Jens Lehmann writes:
> static struct lock_file lock_file;
> +#define SUBMODULE_WITH_GITDIR ((const char *)1)
I don't like very much hardcoded addresses like this. Are you 100% sure
address 1 will never be returned by xstrdup on any platform? The risk is
small if not negligible, but I'm unconfor
Normalize to my personal address, as my ETH addresses will expire
soon. Also add my new corp account to be somewhat futureproof.
Note that despite the private address being first, Google owns the
copyright as long as I am employed there.
Signed-off-by: Thomas Rast
---
.mailmap | 4 +++-
1 file
In commit 0656781fa "git mv" learned to update the submodule path in the
.gitmodules file when moving a submodule in the work tree. But since that
commit update_path_in_gitmodules() gets called no matter if we moved a
submodule or a regular file, which is wrong and leads to a bogus warning
when mov
On Sun, Oct 13, 2013 at 5:19 AM, Miles Bader wrote:
> 2013/10/13 Eric Sunshine :
>> Here "staged".
> ...
>> But here "stage".
>
> The inconsistency is weird, but isn't the term "staged" a bit odd with
> something that affects the future...?
>
> "Apply to the stage" seems a reasonable english phras
2013/10/13 Eric Sunshine :
> Here "staged".
...
> But here "stage".
The inconsistency is weird, but isn't the term "staged" a bit odd with
something that affects the future...?
"Apply to the stage" seems a reasonable english phrasing, but "staged"
seems more awkward...
-miles
--
Cat is power.
On Sun, Oct 13, 2013 at 4:53 AM, Eric Sunshine wrote:
> On Sat, Oct 12, 2013 at 3:04 AM, Felipe Contreras
> wrote:
>> Synonym for --index.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> Documentation/git-apply.txt | 5 -
>> builtin/apply.c | 2 ++
>> 2 files changed, 6 insertio
On Sun, Oct 13, 2013 at 5:03 AM, Eric Sunshine wrote:
> On Sat, Oct 12, 2013 at 3:05 AM, Felipe Contreras
> wrote:
>> diff --git a/t/t5529-push-publish.sh b/t/t5529-push-publish.sh
>> new file mode 100755
>> index 000..2037026
>> --- /dev/null
>> +++ b/t/t5529-push-publish.sh
>> @@ -0,0 +1,70
On Sat, Oct 12, 2013 at 3:05 AM, Felipe Contreras
wrote:
> diff --git a/t/t5529-push-publish.sh b/t/t5529-push-publish.sh
> new file mode 100755
> index 000..2037026
> --- /dev/null
> +++ b/t/t5529-push-publish.sh
> @@ -0,0 +1,70 @@
> +#!/bin/sh
> +
> +test_description='push with --set-publish
On Sat, Oct 12, 2013 at 3:04 AM, Felipe Contreras
wrote:
> Synonym for --index.
>
> Signed-off-by: Felipe Contreras
> ---
> Documentation/git-apply.txt | 5 -
> builtin/apply.c | 2 ++
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-apply.txt
On Sat, 12 Oct 2013, Eric Wong wrote:
This is a follow up to commit e47a8583a20256851e7fc882233e3bd5bf33dc6e
(enable SO_KEEPALIVE for connected TCP sockets).
Just keep in mind that TCP keep-alive is enabled in awkwardly many different
ways on different systems and this patch only supports one
On Oct 13, 2013, at 3:32 AM, Torsten Bögershausen wrote:
> (Please, not top-posting)
Sorry about that
>
>>> On Oct 12, 2013, at 8:47 AM, "brian m. carlson"
>>> wrote:
>>>
On Fri, Oct 11, 2013 at 11:06:17PM -0500, Fernando Ortiz (e2k) wrote:
I'm getting the following error when I do:
(Please, not top-posting)
>> On Oct 12, 2013, at 8:47 AM, "brian m. carlson"
>> wrote:
>>
>>> On Fri, Oct 11, 2013 at 11:06:17PM -0500, Fernando Ortiz (e2k) wrote:
>>> I'm getting the following error when I do:
>>>
>>> git send-email --compose --from Fernando Ortiz --to
>>> forti...@gmail.com
I have a better plans for us reply me ASAP. 2721745...@qq.com
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
экстракт бобов Зеленого кофе характеризуется значительнейшим жиросжигающим
действием http://www.sauna-banya.by/templates/beez/xosxw.htm?C
33 matches
Mail list logo
