Re: git-svn and huge data and modifying the git-svn-HEAD branch directly

Dear diary, on Wed, Mar 01, 2006 at 10:40:01AM CET, I got a letter
where Andreas Ericsson [off-list ref] 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.