Thread (1 message) 1 message, 1 author, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:41

Petr Baudis [off-list ref] 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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help