Re: git merge questions

Don Zickus [off-list ref] writes:

quoted

and then, the digging I suggested yields these:

$ ls -l arch/{ppc64,powerpc}/Kconfig
-rw-rw-r--  1 junio src 24279 Dec 16 12:55 arch/powerpc/Kconfig
-rw-rw-r--  1 junio src 11027 Dec 16 12:58 arch/ppc64/Kconfig
$ git ls-files -s arch/ppc64/Kconfig arch/powerpc/Kconfig
100644 bb2efdd566a9d590d64184b10b097e4b7ed17e95 0       arch/powerpc/Kconfig
100644 c658650af429672267409508b02b38754c11a40f 1       arch/ppc64/Kconfig
100644 8abf1118ebbd59954d098d87679114ffda0e75cb 3       arch/ppc64/Kconfig
..
The result you want in this case is to merge changes between
c65865 (stage1 of old path) and 8abf11 (stage3 of old path) into
bb2efd (the latest contents of the new path) and register it as
the result of merge for arch/powerpc/Kconfig, and remove
arch/ppc64/Kconfig.  So the sequence would be:

$ orig=$(git unpack-file c65865)
$ from_test=$(git unpack-file 8abf11)
$ merge $from_test $orig arch/powerpc/Kconfig
merge: warning: conflicts during merge

I suspect there might be a room for improvement to make this
easier with a new command, if this becomes a common pattern.

Something like:

	$ git resolve-renamed-path arch/ppc64/Kconfig arch/powerpc/Kconfig

to mean "I want the result of this merge to rename ppc64/Kconfig
to powerpc/Kconfig", perhaps?  There are three cases: (1) we
renamed they didn't --- this is the case we are looking at and
there will be stage1 and stage3 but not stage2 for the old path,
and stage0 for the new path; (2) they renamed we didn't --- this
would happen if you pulled test2 into test, and there will be
stage1 and stage2 but not stage3 for the old path, and stage0
for the new path; (3) both of us renamed.

The third case is handled by the merge command automatically.
Old path will not remain to bother you even if the merge of the
new path needs hand-resolving, so you do not need
resolve-renamed-path command to deal with that case.

Now say I didn't know the name of the rename and I had to dig
that up.  Would the following be the right way or is there
something easier?

%git log <renamed file>  #grab the last commit id from here
%git-diff-tree -p <last commit id>  # search for the new file

That would work.

Or an explicit rename detection to see where many of the
neighbouring paths moved (this is very expensive):

	mb=$(git merge-base test test2)
        git diff-tree -r --diff-filter=R -M -l0 --name-status $mb test2

Or the diff-tree between the merge base and your current tree
and perhaps the other tree (this may give a lot of cruft):

	mb=$(git merge-base test test2)
        git diff-tree -r --diff-filter=A --name-status $mb test2