From: Junio C Hamano <junkio@cox.net>
Date: Sat, 23 Sep 2006 19:31:59 GMT
Subject: Re: [RFC][PATCH] for_each_ref() returning heads in wrong order
Message-ID: <7vu02ys7kg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060923160712.5890.73139.stgit@machine.or.cz>

Petr Baudis <pasky@suse.cz> writes:

> Using the #next branch I've now hit a problem with git-fetch-pack
> master choosing refs/bases/master (I geuss created by StGIT) instead
> of refs/heads/master. The old upload-pack returned the refs in the order
> heads-tags-everything_else but the new one just goes for whatever order
> readdir() returns them in (modulo merging with packed refs). I actually
> can't see the difference that caused this right now, though.

I think it is the other way around (the new one sorts, the old
one doesn't).  fetch-pack lets for_each_ref() to pick, but the
wrapper git-fetch I think prepends refs/ and refs/heads as
needed, so if you explicitly say heads/master I do not think you
have a problem.

However, I see a bit bigger problem here.  I think rev-parse
would not complain "master" is ambiguous in your repository,
because it has a fixed list of prefixes ("", refs, refs/tags,
refs/heads, refs/remotes, refs/remotes/%/HEAD) it uses to DWIM
in sha1_file.c::get_sha1_basic(), and refs/bases is not part of
the prefixes.

I suspect we should fix connect.c::count_refspec_match(), which
currently is just a strict tail match, to use the same list of
prefix.