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

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

[tony.luck]

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