"git checkout" says Entry blah would be overwritten by merge ...

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