Re: git merge questions

Johannes Schindelin [off-list ref] writes:

just a thought: maybe in this case -- git fails to recognize a rename -- 
Pasky's idea would have some merit. You could then provide git with some 
extra information a la .git/info/grafts: "Even if you, git, do not believe 
it: this file *was* renamed from blah to blop".

Yeah, except small details such as: where does it record it, and
how does the information presented to the user, and how does the
user tell git that information should be used?

What would be interesting would be to extend on this thing I
just wrote:

    Something like:

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

    to mean "I want the result of this merge to rename ppc64/Kconfig
    to powerpc/Kconfig", perhaps?

I think this would work very nicely even without rename
detectino by the recursive strategy.  What would happen with
resolve strategy is that unchanged paths are removed from
arch/ppc64 and added to arch/powerpc by the usual read-tree
merge rules, and all paths (not just unrecognizable renames --
because resolve would not even try) that have been changed on
the "test" branch would be in stage1+stage3 state in arch/ppc64,
while the corresponding ones in arch/powerpc are collapsed
("only added in test2 branch") to stage0.  The fictional
resolve-renamed-path command (notice that I removed the explicit
"Kconfig" from the sample command line) could go through the
index file, looking for paths that arch/powerpc/ has stage0 and
arch/ppc64 has stage1+3, and perform the renaming merge at that
point.