From: ZAK Magnus <zakmagnus@google.com>
Date: Thu, 21 Jul 2011 20:40:54 GMT
Subject: Re: git fetch --all --depth
Message-ID: <CAAuSN90Ai7KD68fwRtRUkP4tm61=CcEc_9-kH0Dh5mdAT4hOpg@mail.gmail.com>
In-Reply-To: <20110721200455.GC11520@camk.edu.pl>

Looks like a bug. I believe the culprit is add_options_to_argv(),
which is used by fetch_multiple() to copy command line arguments to a
child process, but does not copy the --depth argument. Thus --all (and
everything else that relies on fetch_multiple() or
add_options_to_argv()) ignores --depth.

On Thu, Jul 21, 2011 at 1:04 PM, Kacper Kornet <kornet@camk.edu.pl> wrote:
> On Thu, Jul 21, 2011 at 09:36:55AM -0700, Junio C Hamano wrote:
>> Kacper Kornet <kornet@camk.edu.pl> writes:
>
>> > I have just discovered that when I use:
>
>> > git fetch --all --depth=<n>
>
>> > the history is not deepened. Is the any specific reason for it or is it
>> > a bug?
>
>> The above is not specific enough to judge if you found a bug or if it is a
>> user error.
>
> To be more specific, the steps to reproduce:
>
> $ git clone --depth=1 git://git.kernel.org/pub/scm/git/git.git
> $ cd git
> $ git fetch --depth 2 --all
>
> and the last command does nothing, while
>
> $ git fetch --depth 2
>
> deepens the clone by 2 repos, as expected.
>
>> IIRC, --depth=<n> is not "deepen by <n>", but "make sure I have at least
>> <n> from the updated tip(s)".  The shallow-clone hack gives you quite
>> useless (even though it may be internally consistent) semantics if you
>> shallow-cloned way in the past and fetched with --depth after the other
>> side added many more commits than <n>, as you cannot guess what the right
>> value of <n> should be without actually fetching without --depth.
>
> That is true. Also, from esthetic point of view, sometimes I miss the
> functionality to deepen the full repository. For example git fetch
> --depth 0 could do it. Now I have to do git fetch --depth
> <very_large_number>
>
> --
>  Kacper Kornet
>