Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a
letter
where Andreas Ericsson <ae op5.se> 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.
-
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://vge
r.kernel.org/majordomo-info.html
|