Re: [PATCH] Do not fetch tags on new shallow clones

From: Shawn Pearce <spearce@spearce.org>
Date: Jan 5, 2012, 15:16 UTC
Message-ID: <CAJo=hJse=6+9DdDgwJOEas1kdbx946SSKeTjEMZrYUA6V+h=1Q@mail.gmail.com>
In-Reply-To: <7vfwfuofnk.fsf@alter.siamese.dyndns.org>

2012/1/4 Junio C Hamano <gitster@pobox.com>:

Show 5 quoted lines

> Shawn Pearce <spearce@spearce.org> writes:
>> ... Its useful because cloning a branch immediately after it
>> has been tagged for a release should have `git describe` provide back
>> the name of the release from the tag (assuming of course no new
>> commits were made since the tag).

...

Show 8 quoted lines

> ... this thing, once you have a "single ref only" stuff working.  After
> Linus announces that he released 3.2, you would do the poor emulation of
> "git archive | tar xf -" with something like:
>
>    git clone --single=v3.2 --shallow $there linux-3.2
>
> and your "git describe" should fall out as a natural consequence out of
> everything else, without the usual "tag following" semantics, no?

I said "branch" not "tag". Of course a single ref clone might be able to be used on a tag.

If my project maintainer tags a release from "maint" and announces that, I should also be able to shallow clone maint and pick up the tag automatically if it is within the depth I have asked for from the server.

Consider this case, a client clones shallow with a depth of 1. Then does normal `git fetch` to keep up-to-date with the project. When the project places a new tag on a branch, our shallow follower will automatically get that tag during her next `git fetch`, because auto following tags is enabled in fetch and the tag's referent was included in the pack. Why is this case permitted to get a tag, and shallow clone is not?

Actually, I think you might find that a shallow client with depth of 1 will automatically pick up a missing tag at the branch head on its next `git fetch`. It will see the tag's ^{} line advertise an object it has, and ask for the tag.

We really should support auto-following tags within the history space the client already has. Its mostly done for us with the include-tag capability, the client just needs to make sure it asks for it from the server, and check to see if any tag reference points to an object it has.

> you would do the poor emulation of
> "git archive | tar xf -" with something like:
>
>    git clone --single=v3.2 --shallow $there linux-3.2

Is it really that poor of an emulation? Like tar, we get only one copy of each file (assuming depth 1). Assuming --format=tar.gz, both are compressed. I wonder how much better or worse the Git cross-object delta compression is than the libz rolling window. I could see how Git might be able to compress something like C source code smaller than tar | gzip by using delta compression on related files (e.g. Makefile in every directory, or *.h and *.c files pairing by type). An added advantage of the shallow clone is you can incrementally update that stream, as its easy to fetch a v3.2.1 patch release, or apply a patch and record it on top.