Re: [RFC][PATCH] for_each_ref() returning heads in wrong order

From: Junio C Hamano <junkio@cox.net>
Date: Sep 23, 2006, 19:31 UTC
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:

Show 6 quoted lines

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