Re: git merge questions

Don Zickus <dzickus@gmail.com> writes:

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-test

With 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/Kconfig

5. 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