From: "Jeff King" <peff@xxxxxxxx>
Sent: Thursday, August 23, 2012 8:56 PM
On Thu, Aug 23, 2012 at 08:13:29PM +0100, Philip Oakley wrote:
>>I'm still suspicious about the logic related to args.fetch_all and
>>args.depth, but I don't think I've made anything worse.
>
>I think the point of that is that when doing "git fetch-pack --all
>--depth=1", the meaning of "--all" is changed from "all refs" to
>"everything but tags".
>
There is a comment in \git\Documentation\technical\shallow.txt that
"- If you deepen a history, you'd want to get the tags of the
newly stored (but older!) commits. This does not work right now."
which may be the source of this restriction. That is, how is the
depth
of the tag fetching to be restricted to the requested depth count?
[assuming I've undestood the problem correctly]
I don't think this is about deepening, but rather about making sure we
remain shallow for the initial fetch. Remember that this is on the
"fetch-pack --all" code path, which used to be used by "git clone"
when
it was a shell script (these days, clone is a C builtin and will
actually feed the list of refs to fetch-pack).
OK
This code blames back to:
commit 4bcb310c2539b66d535e87508d1b7a90fe29c083
Author: Alexandre Julliard <julliard@xxxxxxxxxx>
Date: Fri Nov 24 16:00:13 2006 +0100
fetch-pack: Do not fetch tags for shallow clones.
A better fix may be to only fetch tags that point to commits that
we
are downloading, but git-clone doesn't have support for following
tags. This will happen automatically on the next git-fetch though.
So it is about making sure that "git clone --depth=1" does not
accidentally pull a single commit from v1.0, v1.1, v1.2, and so forth,
losing the purpose of using --depth in the first place. These days it
is
largely irrelevant, since this code path is not followed by clone, and
clone will automatically restrict its list of fetched refs to a single
branch if --depth is used.
The bug that shallow.txt talks about (and which is mentioned in that
commit message) is that we will not properly auto-follow tags during
such a clone (i.e., when we fetch a tag because it is pointing to a
commit that we already have or are already pulling). I'm not sure if
that is still the case or not. But assuming your workflow is something
like:
[make an initial, cheap clone]
git clone --depth=1 $repo
[the next day, you do a regular fetch, which will just get new stuff
on top of what you already have]
git fetch
Then that second fetch will auto-follow the tags, anyway. And that is
what the commit message is pointing: it's a bug, but one you can work
around.
I hadn't appreciated that the fetch would limit itself to the original
shallow
depth. I'd gained the impression that one need to use the --depth to
control what was being fetched.
It may be (?) that it is a good time to think about a 'datedepth'
capability to bypass the current counted-depth shallow fetch that can
cause so much trouble. With a date limited depth the relevant tags
could also be fetched.
I don't have anything against such an idea, but I think it is
orthogonal
to the issue being discussed here.
OK. I'll stick it on my slow-burner pile ;-)
-Peff
--
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