Re: git merge questions

From: Junio C Hamano <junkio@cox.net>
Date: Dec 17, 2005, 01:32 UTC
Message-ID: <7vd5jwcxtk.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0512170056380.11000@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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.