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 HamanoRe: git fetch --all --depth
Kacper Kornet <kornet@camk.edu.pl> writes:
Show 6 quoted lines
> 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.
Re: git fetch --all --depth
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.
Show 6 quoted lines
> 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
Re: git fetch --all --depth
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:
Show 40 quoted lines
> 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 >