I do not work on the kernel myself so I'll probably get the details wrong, but I am guessing here is what you have:
- 2.6.14.z has arch/ppc64/Kconfig;
- Your "test" branch has arch/ppc64/Kconfig. You may or may
not have changes since 2.6.14.z on that file;
- "test2" branch has 2.6.15-rc4, which has the file at
arch/powerpc/Kconfig;
Then, with the current branch being "test2", you pulled "test" into it.
- Untouched [by whom???] files from arch/{ppc64,powerpc}/ were
merged correctly and you find the result of merge under
arch/powerpc --- after all you are applying changes on top of
2.6.15-rc4 and you want them under arch/powerpc as the
upstream has; - arch/ppc64/Kconfig was modified [by whom???] and merge was
left unresolved.
I suspect these:
ls -l arch/ppc64/Kconfig <1>
git ls-files -s arch/ppc64/Kconfig <2>
ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>
git ls-files -s arch/powerpc/Kconfig <4><1> has the file from your "test" branch based on 2.6.14z;
<2> shows that same file;
<3> may show the three variants (I am not sure about this);
<4> has 2.6.15-rc4 version at stage 3 and merge base version at
stage 1 (I am not absolutely certain what stage 1 has, and
also am puzzled why stage 2 is not there --- if the
recursive strategy figured out renames it should have the
contents of arch/ppc64/Kconfig from test branch there).The safest (however most primitive) way I can think of to go from here is:
1. figure out the merge-base Kconfig file's contents.
$ mb=$(git merge-base refs/heads/test refs/heads/test2)
$ git ls-tree $(mb) arch/powerpc/Kconfig arch/ppc/Kconfig I do not know which path the merge base has, but it should
have either one of those. Note the blob object name (call it
$oSHA1).
2. extract three versions.
$ git ls-tree refs/heads/test2 arch/powerpc/Kconfig
$ git ls-tree refs/heads/test arch/powerpc/Kconfig Note the blob object name from these two as well (call them
$aSHA1, and $bSHA1).
3. merge those three.
$ git cat-file blob $oSHA1 >orig
$ git cat-file blob $aSHA1 >from-test2
$ git cat-file blob $bSHA1 >from-test
$ merge from-test2 orig from-testWith luck from-test2 would contain a clean automerge result, or you will get <<< === >>> conflict markers. Resolve them in the file, and then:
4. resolve the index and remove cruft.
$ cat from-test2 >arch/powerpc/Kconfig
$ rm -f arch/ppc64/Kconfig orig from-test2 from-test
$ git update-index --add --remove \
arch/ppc64/Kconfig arch/powerpc/Kconfig5. if there is no other merge cruft, commit.
$ git commit
What puzzles me is that I think it is supposed to have done all the above for you. Namely:
$ ls -l arch/ppc64/Kconfig <1>
$ git ls-files -s arch/ppc64/Kconfig <2>
$ ls -l arch/powerpc/Kconfig arch/powerpc/Kconfig~* <3>
$ git ls-files -s arch/powerpc/Kconfig <4><1> should not remain --- recursive merge could have notied that the file was moved. <2> ditto. <3> arch/powerpc/Kconfig should be there with possibly merge conflict markers. <4> stage1 with merge base version (possibly renamed), stage2 with test2 version, stage3 with your test version (definitely renamed).
and after editing arch/powerpc/Kconfig to resolve conflicts, you should be able to just say:
$ git update-index arch/powerpc/Kconfig
$ git commit
Don Zickus
