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

Alexandre Julliard· Nov 24, 2006, 15:00 UTC · lore

[PATCH 5/5] 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.

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

Show changes to fetch-pack.c +2 −1

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

Junio C Hamano· Nov 24, 2006, 20:28 UTC · re: Alexandre Julliard · lore

Alexandre Julliard <julliard@winehq.org> writes:

Show 5 quoted lines

> 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?

Johannes Schindelin· Nov 25, 2006, 19:01 UTC · re: Alexandre Julliard · lore

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?

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