Re: Moved files and merges

From: Junio C Hamano <junkio@cox.net>
Date: Sep 4, 2005, 19:10 UTC
Message-ID: <7vvf1gejjf.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0509041329340.23242@iabervon.org>

Daniel Barkalow <barkalow@iabervon.org> writes:

> I think this is actually quite a regular merge, and I think we should be 
> able to offer some assistance. The situation with K is normal: case #3ALT. 
> If someone introduces a file and there's no file or directory with that 
> name in other trees, we assume that the merge should include it.

I was not particularly interested in discussing the initial merge, which is a perfectly regular merge as you said. I was more focusing on reusing the tree-structure change information we _could_ find in merge #3 when we make later merges, because that merge is something the user did in the past and would be a good guide for guessing what the user wants to happen to this round.

There is no question about K in 'keeping addition' case. It gets interesting only when the first merge prefered 'reject addition by them' and we would want to reuse that preference in the second merge. But as I tried to clarify in the "a couple of things worth mentioning" message, there is no fundamental reason to treat removal and addition any differently. It is just a way to reduce unnecessary conflicts.

> Most likely, this just means that we 
> should not commit automatically, but have the user test the result first.

No question about it again.

> Of course, read-tree is in flux at 
> the moment, so making more structural changes to it at the same time is 
> awkward.

Doing this in read-tree is a bit premature. I'd prefer a scripted solution first to see what we want and how well it works in practice.

Show 8 quoted lines

>   1
>  / \
> 0-2-3-5-7
>    \   /
>     4-6
>
> It shouldn't matter to the merge at 7 if the 2-3 reorganization was done 
> locally, by applying a patch, or by merging.

There was another problem in my message that treated #3 specially. I did it that way primarily because I wanted to have an algorithm that needs to look only limited (namely, one) number of commits, more than what we currently look at. The problem is that the trail #0..#1..#3 (in the example in second message, whose rename probably happened between #0 and #1) may change the contents of the renamed file so drastically that diff between #2 and #3 may not look like rename anymore, while we could still detect it if we followed the whole trail and looked for renames between each commit on it.