[PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.

[PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.

[Alexandre Julliard]

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.

Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
 fetch-pack.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/fetch-pack.c b/fetch-pack.c
index bb310b6..80979b8 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -342,7 +342,8 @@ static void filter_refs(struct ref **ref
 		if (!memcmp(ref->name, "refs/", 5) &&
 		    check_ref_format(ref->name + 5))
 			; /* trash */
-		else if (fetch_all) {
+		else if (fetch_all &&
+			 (!depth || strncmp(ref->name, "refs/tags/", 10) )) {
 			*newtail = ref;
 			ref->next = NULL;
 			newtail = &ref->next;
-- 
1.4.4.1.ga335e

-- 
Alexandre Julliard

Re: [PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.

[Junio C Hamano]

Alexandre Julliard <julliard@winehq.org> writes:

> 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.
>
> Signed-off-by: Alexandre Julliard <julliard@winehq.org>

All five patches look sane.  Thanks.

The last one made me go "Huh?" at first, but it indeed is an
improvement.  It wouldn't make much sense to "shallow clone" by
two commits near the tip of the 'master' branch from Linus's
kernel, and then having to "shallow clone" all of his tags down
to v2.6.12-rc2, each with two commit depths limit.

I however think a better "fix" is not to use shallow "clone" but
shallowly fetch branches you are interested in into an empty
repository for such a use scenario.  Just like making two-depth
shallow copy of all the old tags do not help when the user is
interested in the recent history of the tip of the 'master'
branch, it does not help much to get near the tip of all other
branches with a uniform depth when one particular branch from a
remote repository is of interest.  I can imagine that somebody
who fully follows the 'master' branch from git.git repository
from time to time wants to take a peek at near the tip of 'pu'
(perhaps because the 'shallow clone' topic is interesting) or
wants to fetch near the tip of Jakub's gitweb work to see what
area is still being improved, and shallowly fetching them into a
repository that has full history of my 'master' would be a
useful way to do so, provided if 'pu' and/or Jakub's tree have
deep enough histories since 'master' that the benefit of saved
bandwidth and disk usage outweighs the complexity of "shallow".

I haven't tried these usage scenarios myself.  I wonder if a
shallow "clone" with non-uniform depths from possible more than
one repository work sensibly?

Re: [PATCH 5/5] fetch-pack: Do not fetch tags for shallow clones.

[Johannes Schindelin]

Hi,

the other 4 patches look good to me (fixing a few typos/thinkos). However, 
I think there must be a way to fetch tags for clones, when it is possible 
for fetches. Especially since fetch gets closer to including the features 
needed for "clone" (regexes for remote names, storing packs, ...)

Ciao,
Dscho

P.S.: I just realized that send-pack and receive-pack are not at all aware 
of shallow repos. Maybe both should check for a shallow repo, and die() on 
it?