# git fetch --all --depth

4 messages from 2011-07-20 to 2011-07-21. Participants: Kacper Kornet, Junio C Hamano, ZAK Magnus.
Thread: https://gitlist.dev/t/27870

## Kacper Kornet, 2011-07-20 22:39

Subject: git fetch --all --depth
Message-ID: <20110720223902.GA6675@camk.edu.pl>
URL: https://gitlist.dev/e/20110720223902.GA6675%40camk.edu.pl

```
Hi,

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?

-- 
  Kacper Kornet

```

## Junio C Hamano, 2011-07-21 16:36

Subject: Re: git fetch --all --depth
Message-ID: <7v1uxj4ml4.fsf@alter.siamese.dyndns.org>
URL: https://gitlist.dev/e/7v1uxj4ml4.fsf%40alter.siamese.dyndns.org
In-Reply-To: <20110720223902.GA6675@camk.edu.pl>

```
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.

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.

```

## Kacper Kornet, 2011-07-21 20:04

Subject: Re: git fetch --all --depth
Message-ID: <20110721200455.GC11520@camk.edu.pl>
URL: https://gitlist.dev/e/20110721200455.GC11520%40camk.edu.pl
In-Reply-To: <7v1uxj4ml4.fsf@alter.siamese.dyndns.org>

```
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

```

## ZAK Magnus, 2011-07-21 20:40

Subject: Re: git fetch --all --depth
Message-ID: <CAAuSN90Ai7KD68fwRtRUkP4tm61=CcEc_9-kH0Dh5mdAT4hOpg@mail.gmail.com>
URL: https://gitlist.dev/e/CAAuSN90Ai7KD68fwRtRUkP4tm61%3DCcEc_9-kH0Dh5mdAT4hOpg%40mail.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
>

```