# RE: new file leaked onto release branch

2 messages from 2005-12-19 to 2005-12-19. Participants: Brown, Len, Junio C Hamano.
Thread: https://gitlist.dev/t/2874

## Brown, Len, 2005-12-19 03:21

Subject: RE: new file leaked onto release branch
Message-ID: <F7DC2337C7631D4386A2DF6E8FB22B30056F9395@hdsmsx401.amr.corp.intel.com>
URL: https://gitlist.dev/e/F7DC2337C7631D4386A2DF6E8FB22B30056F9395%40hdsmsx401.amr.corp.intel.com

```
 
>This theory however does not seem to match what really happened.
>Len did mention that he has "5165" branch (there is a commit
>marked "Pull 5165 into release branch" near a problematic
>merge), but he did not say he also has a 5165 tag; the bug does
>not trigger if you do not have the tag of the same name.  Also
>if this theory holds true, the problematic commit should have a
>commit whose object name begins with 5165 as the second parent
>but that is not the case.  And the problem happened with a
>commit that is not a merge between release/test and topic
>branch anyway; it is with an "Auto-update from upstream" commit.

Per Tony's topic-branches howto, I do plenty of branching,
where the topic branch name , #### below , is a 4-digit number:

git checkout -b #### linus

and I use the wrapper script to do this:

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


But
1. I don't create tags with #### names, indeed, I never use tags at all
2. I agree that while #### names may be an area of a potential
   problem, it may not be related to the observed failure.  This is
   because the file in question was added to to a topic branch called "acpica"
   which IIR never interacted in any way with a branched named ####,
   but only with the branches called "linus" and "test".

>So I am still puzzled by the "where did this file come from"
>problem.  The most plausible explanation was the driver error
>mentioned already in the thread: "update-index --add" in the
>middle of merge with manual committing.

I too suspect that a failed automatic merge is related.
Likely the sequence of events is not something that either
a git expert or a git beginner would ever issue, but takes
somebody like me who knows just enough to be dangerous:-)

-Len

```

## Junio C Hamano, 2005-12-19 09:16

Subject: Re: new file leaked onto release branch
Message-ID: <7vvexlh2ga.fsf@assigned-by-dhcp.cox.net>
URL: https://gitlist.dev/e/7vvexlh2ga.fsf%40assigned-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.

```