I'm a little closer to understanding how I got into the situation where I made that ugly commit last week that included 10 files that I didn't want, because I just had another failed merge (but this time I know how to recover :).
The approximate sequence of events was: SGI told me one of the pending fixes in my test tree was causing an oops during boot on a whole class of machines. They asked whether it could get into 2.6.13. I agreed it was a good candidate, and ran my script to pull it from its temporary branch (named prarit-bus-sysdata in this case) into my release branch. The script is trivial after the argument sanity checks it just does: $ git checkout release && git resolve release prarit-bus-sysdata "Pull prarit-bus-sysdata into release branch" Only one file was touched by this: arch/ia64/sn/kernel/io_init.c I think that this would have gone through a non-trivial merge as this file had subsequently been touched by another patch, but the merge did complete automatically. Next I pushed the release branch up to kernel.org, asked Linus to pull. I then applied a totally independent patch to a new branch, pulled it to the test branch, and pushed to kernel.org ... net effect was that my tree ended up in "git checkout test" state. Later I noticed that Linus had pulled from my tree (and from other trees too), so I pulled his latest tree down from kernel.org using: $ git checkout linus && git pull linus Then I tried to update my test branch with these changes using: $ git checkout test && git resolve test linus "Auto-update from upstream" This spat out these messages: fatal: Entry 'arch/ia64/sn/kernel/io_init.c' would be overwritten by merge. Cannot merge. Trying to merge 8065e2... into cde7fe... fatal: Entry 'arch/ia64/hp/sim/boot/boot_head.S' would be overwritten by merge. Cannot merge. There is one obvious bug here: "git checkout test" failed with the first error (from its invocation of git-read-tree) ... but returned an exit status of 0, so my script went ahead and tried to do the resolve, which the && should have prevented. The less obvious (i.e. I have no clue what I did wrong) thing is why the "git checkout" had a problem with this file. Yes, it had been touched earlier ... but in a way that should have left the index up to date. And two subsequent "git checkout" commands had switched first to the test branch, and then to the linus branch without a complaint. -Tony - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
