Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a letter where Andreas Ericsson <ae@xxxxxx> said that... > 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. - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html