Daniel Barkalow <[EMAIL PROTECTED]> 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

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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to