RE: new file leaked onto release branch

From: Brown, Len <len.brown@intel.com>
Date: Dec 14, 2005, 22:06 UTC
Message-ID: <F7DC2337C7631D4386A2DF6E8FB22B30056B86DD@hdsmsx401.amr.corp.intel.com>

Show 16 quoted lines

>I pointed out one anomaly which is the commit should never have
>been created because it was not even a fast forward but already
>up-to-date case, and it was followed up with exchange of a few
>messages between Linus and you.  But even if we got that mixed
>up, the resulting merge should not have contained the file
>neither parents had.  That part worries me the most.
>
>One question.  You mentioned these in your message, you have
>a "git.commit wrapper" that contains these lines:
>
>    git-update-index --add --remove `quilt files`
>    git commit
>
>I am not familiar with 'quilt', but is "quilt files" the command
>to show the list of files with patches applied to the working
>tree?

yes, but only by the last applied "on the top of the stack." When I do a commit, there is only 1 patch applied so this works okay. (then I push the next patch after the commit and repeat...)

Show 10 quoted lines

>If so, the above do tell git about the modified (including added
>or removed) files that the applied quilt patches touch, which
>sounds like the correct thing to do.
>
>But the resulting commit from that procedure would not be a
>merge commit, and the commit in question that had the rsinfo
>file magically appeared from nowhere is a merge, so this does
>not seem to have much to do with the current problem...
>
>Still puzzlled, sorry.

I'm not stuck by this problem, since I created a new release branch based before the funny merge and it seems to be working properly. I'm sorry I can't re-create the problem again. Next time something like this happens and I notice it I'll be sure to keep the ingredients for the failure on hand.

thanks, -Len