Brown, LenShow 10 quoted lines
>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
