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:
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
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.
Trying to merge 8065e2... into cde7fe...
fatal: Entry 'arch/ia64/hp/sim/boot/boot_head.S' would be overwritten by merge.
There is one obvious bug here: "git checkout test" failed with the first error
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
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.
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