Re: new file leaked onto release branch

From: Junio C Hamano <junkio@cox.net>
Date: Dec 19, 2005, 09:16 UTC
Message-ID: <7vvexlh2ga.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30056F9395@hdsmsx401.amr.corp.intel.com>

"Brown, Len" <len.brown@intel.com> writes:

> 2. I agree that while #### names may be an area of a potential
>    problem, it may not be related to the observed failure.

I made it a potential problem by mistake and left it so for a couple of weeks, but there was no reason for #### names to be a problem. Even when #### is a unique prefix of a valid object name, if you have .git/refs/heads/#### branch, that should be the one that takes precedence over a random object name, and that is what the fixed code does. Sorry about the earlier breakage.

Just please keep in mind that the search order is "tags then heads" (see sha1_name.c::get_sha1_basic()::prefix[]), so if you happen to have #### branch *and* tag then you will be merging the tag with this:

> git checkout test && git merge "Pull #### into test branch" test ####

If the git.merge wrapper you posted earlier is always used to pull a topic branch, it might be safer to update it to do:

	git checkout "$2" &&
        git merge "Pull $1 into $2 branch" HEAD "refs/heads/$1"

to disambiguate.