Re: Moved files and merges

[Junio C Hamano <junkio@cox.net>]

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.

>   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.