Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a letter
where Andreas Ericsson <ae@op5.se> said that...
quoted text
> It already does. The search order is this, for a ref named 'foo':
> 	$GIT_DIR/foo
> 	$GIT_DIR/refs/foo
> 	$GIT_DIR/refs/tags/foo
> 	$GIT_DIR/refs/heads/foo

Actually, I've hit this recently when supporting an unhappy user on
#git, and I didn't manage to find anything in the archives (but perhaps
I missed it). Is there a particular reason why tags are checked first
than branches?

Why not:

(i) I _think_ that it would be less of a surprise if a branch would be
checked first.

(ii) E.g. Cogito output (cg-status -g) is very confusing when you have a
naming clash - cg-object-id foo will show tag commit ID, but cg-status -g
will say that the "foo" branch has a different commit ID (and it is
_right_).

(iii) Many operations will stop making sense (cg-merge foo, and even
cg-fetch foo will be confused), while in case of the opposite way I can't
think of any command still not making sense.

(iv) A security hole when you auto-fetch tags from remote repositories
- you could then be misled to merge something totally different when the
attacker will introduce a naming clash to your refs hierarchy.

Actually, I'm almost inclined to suggest making Git fail violently in
case of an ambiguous name.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Right now I am having amnesia and deja-vu at the same time.  I think
I have forgotten this before.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html