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