RE: new file leaked onto release branch

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