Re: git merge questions

Don Zickus <dzickus@gmail.com> writes:

> Now over the course of 2.6.15 the arch/ppc64 was renamed to
> arch/powerpc.  Fine. The merge algorithms handled all the unchanged
> files properly.  However arch/ppc64/Kconfig was modified and the
> merging was left unresolved.  In fact there is no file no merge
> against (because it moved).  So 'git-ls-files -u' only shows stage 1+3
> (no stage 2, of course).
>
> How do I merge those changes?  I don't know enough about all the git
> commands to figure this out, especially how to take advantage of the
> stage 1, 2, and 3 files.

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


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html