On 26 Nov 2013, at 07:17, René Scharfe wrote:
> Am 26.11.2013 01:04, schrieb Nick Townsend:
>> My first git patch - so shout out if I’ve got the etiquette wrong! Or
>> of course if I’ve missed something.
>
> Thanks for the patches! Please send only one per message (the second
> one as a reply t
On 26 Nov 2013, at 14:18, Junio C Hamano wrote:
> René Scharfe writes:
>
>> Thanks for the patches! Please send only one per message (the second
>> one as a reply to the first one, or both as replies to a cover letter),
>> though -- that makes commenting on them much easier.
>>
>> Side note:
On 26 Nov 2013, at 14:38, Heiko Voigt wrote:
> Hi,
>
> I like where this is going.
>
> On Tue, Nov 26, 2013 at 04:17:43PM +0100, René Scharfe wrote:
>> Am 26.11.2013 01:04, schrieb Nick Townsend:
>>> + strbuf_addstr(&dotgit, work_tree);
>>> + strbuf_addch(&dotgit, '/');
>>>
On 26 Nov 2013, at 16:28, René Scharfe wrote:
> Am 26.11.2013 23:18, schrieb Junio C Hamano:
>> René Scharfe writes:
>>
>>> Thanks for the patches! Please send only one per message (the second
>>> one as a reply to the first one, or both as replies to a cover letter),
>>> though -- that makes
On Sun, Nov 24, 2013 at 10:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> diff --git a/t/t5536-fetch-shallow.sh b/t/t5536-fetch-shallow.sh
> index e011ead..95b6313 100755
> --- a/t/t5536-fetch-shallow.sh
> +++ b/t/t5536-fetch-shallow.sh
> @@ -141,4 +141,26 @@ EOF
> )
> '
>
> +test_expect_success 'f
On Sun, Nov 24, 2013 at 10:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> clone_local() does not handle $SRC/shallow. It could be made so, but
> it's simpler to use fetch-pack/upload-pack instead.
>
> This used by be caught by the check in upload-pack, which is triggered
s/used by/used to/
> by transport_
Am 26.11.2013 23:18, schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Thanks for the patches! Please send only one per message (the second
>> one as a reply to the first one, or both as replies to a cover letter),
>> though -- that makes commenting on them much easier.
>>
>> Side note: Docume
Hi,
I like where this is going.
On Tue, Nov 26, 2013 at 04:17:43PM +0100, René Scharfe wrote:
> Am 26.11.2013 01:04, schrieb Nick Townsend:
> > + strbuf_addstr(&dotgit, work_tree);
> > + strbuf_addch(&dotgit, '/');
> > + if (args->treepath) {
> > +
Duy Nguyen writes:
> On Tue, Nov 26, 2013 at 5:20 AM, Junio C Hamano wrote:
>> Hmph. the use of ->util field in this patch feels that it was
>> something commit-slab data structure was invented to solve.
>
> Good stuff! Thanks.
>
>>> + if (c->util == NULL)
>>> +
Jonathan Nieder writes:
> Junio C Hamano wrote:
>
>> I have a feeling that the
>> current "not copy to fix it to a stable value, but look into
>> .gitmodules as a fallback" was not a designed behaviour for the
>> other properties, but was done by accident
"Andrés G. Aragoneses" writes:
> From 4f3b24379090b7b69046903fba494f3191577b20 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andr=C3=A9s=20G=2E=20Aragoneses?=
> Date: Tue, 26 Nov 2013 12:38:19 +0100
> Subject: [PATCH] transport: Catch non positive --depth option value
Please do not leave these fou
René Scharfe writes:
> Thanks for the patches! Please send only one per message (the second
> one as a reply to the first one, or both as replies to a cover letter),
> though -- that makes commenting on them much easier.
>
> Side note: Documentation/SubmittingPatches doesn't mention that (yet),
Krzesimir Nowak writes:
> Overriding an @additional_branch_refs configuration variable with
> value ('wip') will make gitweb to show branches that appear in
> refs/heads and refs/wip (refs/heads is hardcoded). Might be useful for
> gerrit setups where user branches are not stored under refs/heads
A #! line in these files is misleading, since these scriptlets are
meant to be sourced with '.' (using whatever shell sources them)
instead of run directly using the interpreter named on the #! line.
Removing the #! line shouldn't hurt syntax highlighting since
these files have filenames ending wi
On Sun, Nov 24, 2013 at 10:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> Pushing from a shallow clone using today's send-pack and receive-pack
> may work, if the transferred pack does not end up at any graft
> points. If it does, recent receive-pack that does connectivity check
> will reject the push. If r
Junio C Hamano wrote:
> I have a feeling that the
> current "not copy to fix it to a stable value, but look into
> .gitmodules as a fallback" was not a designed behaviour for the
> other properties, but was done by accident and/or laziness.
It was designed
Antoine Pelisse writes:
> Some buffers created with PATH_MAX length are not checked when being
> written, and can overflow if PATH_MAX is not big enough to hold the
> path.
Perhaps it is time to update all of them to use strbuf? The callers
of prefix_filename() aren't that many, and all of them
Jens Lehmann writes:
> Am 25.11.2013 22:01, schrieb Junio C Hamano:
>> Jens Lehmann writes:
>>
>>> Looking good to me. Please add tests for "diff.ignoreSubmodules"
>>> and "submodule..ignore", the latter both in .gitmodules and
>>> .git/config. While doing some testing for this thread I found a
Hi,
Thanks for tackling this. This review will be kind of nitpicky, as a
way to save time when reviewing future patches.
Andrés G. Aragoneses wrote:
> From 4f3b24379090b7b69046903fba494f3191577b20 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Andr=C3=A9s=20G=2E=20Aragoneses?=
> Date: Tue, 26 Nov
Am 26.11.2013 16:17, schrieb René Scharfe:
> Am 26.11.2013 01:04, schrieb Nick Townsend:
>> diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
>> index b97aaab..b4df735 100644
>> --- a/Documentation/git-archive.txt
>> +++ b/Documentation/git-archive.txt
>> @@ -11,6 +11,7 @@
Am 25.11.2013 22:01, schrieb Junio C Hamano:
> Jens Lehmann writes:
>
>> Looking good to me. Please add tests for "diff.ignoreSubmodules"
>> and "submodule..ignore", the latter both in .gitmodules and
>> .git/config. While doing some testing for this thread I found an
>> inconsistency in git show
Some buffers created with PATH_MAX length are not checked when being
written, and can overflow if PATH_MAX is not big enough to hold the
path.
Some of the use-case are probably impossible to reach, and the program
dies if the path looks too long. When it would be possible for the user
to use a lon
Am 26.11.2013 01:04, schrieb Nick Townsend:
> My first git patch - so shout out if I’ve got the etiquette wrong! Or
> of course if I’ve missed something.
Thanks for the patches! Please send only one per message (the second
one as a reply to the first one, or both as replies to a cover letter),
th
On Tue, Nov 26, 2013 at 5:20 AM, Junio C Hamano wrote:
> Hmph. the use of ->util field in this patch feels that it was
> something commit-slab data structure was invented to solve.
Good stuff! Thanks.
>> + if (c->util == NULL)
>> + c->util = bitmap;
>> +
On Tue, Nov 26, 2013 at 4:53 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> When we receive a pack and the shallow points from another repository,
>> we may want to add more shallow points to current repo to make sure no
>> commits point to nowhere. However we do not want to add u
On Tue, Nov 26, 2013 at 3:08 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Dumb commit walker does not care about .git/shallow and until someone
>> steps up to make it happen, let's not publish shallow clones using
>> dumb protocols.
>>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>
jrnie...@gmail.com wrote on Mon, 25 Nov 2013 12:58 -0800:
> The git p4import documentation has suggested git p4 as a better
> alternative for more than 6 years. (According to the mailing list
> discussion when it was moved to contrib/, git-p4import has serious
> bugs --- e.g., its incremental mode
>From 4f3b24379090b7b69046903fba494f3191577b20 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Andr=C3=A9s=20G=2E=20Aragoneses?=
Date: Tue, 26 Nov 2013 12:38:19 +0100
Subject: [PATCH] transport: Catch non positive --depth option value
Instead of simply ignoring the value passed to --depth
option when it
On Tue, Nov 26, 2013 at 5:43 PM, "Andrés G. Aragoneses"
wrote:
> On 26/11/13 04:06, Duy Nguyen wrote:
>> On Tue, Nov 26, 2013 at 6:34 AM, "Andrés G. Aragoneses"
>> wrote:
>>> On 22/11/13 02:18, Duy Nguyen wrote:
On Fri, Nov 22, 2013 at 3:18 AM, Junio C Hamano wrote:
> Have you run the t
On 26/11/13 04:06, Duy Nguyen wrote:
> On Tue, Nov 26, 2013 at 6:34 AM, "Andrés G. Aragoneses"
> wrote:
>> On 22/11/13 02:18, Duy Nguyen wrote:
>>> On Fri, Nov 22, 2013 at 3:18 AM, Junio C Hamano wrote:
Have you run the tests with this patch? It seems that it breaks
quite a lot of them
On Mon, 2013-11-25 at 11:32 -0800, Junio C Hamano wrote:
> Krzesimir Nowak writes:
>
> > On Fri, 2013-11-22 at 09:34 -0800, Junio C Hamano wrote:
> >> Krzesimir Nowak writes:
> >>
> >> > Running 'make GITWEB_WANTED_REFS="heads wip" gitweb.cgi' will create a
> >> > gitweb CGI script showing bran
Overriding an @additional_branch_refs configuration variable with
value ('wip') will make gitweb to show branches that appear in
refs/heads and refs/wip (refs/heads is hardcoded). Might be useful for
gerrit setups where user branches are not stored under refs/heads/.
Signed-off-by: Krzesimir Nowak
Heikki Hokkanen writes:
> On Sat, Nov 23, 2013 at 4:42 PM, Johannes Sixt wrote:
>> Gah! This adds a fork+exec each time the prompt is shown. Not good,
>> particularly on Windows.
>>
>> Since your intent is to disable the prompt in the home directory,
>> wouldn't that mean that most of the time y
33 matches
Mail list logo
