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@xxxxxxxxxxx> wrote: > On Thu, Jul 21, 2011 at 09:36:55AM -0700, Junio C Hamano wrote: >> Kacper Kornet <kornet@xxxxxxxxxxx> 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 > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html