Re: Improvements to diff3 (merge) performance

2011-06-13 Thread Greg Hudson
On Mon, 2011-06-13 at 07:00 -0400, Morten Kloster wrote: > I assume he has discussed this elsewhere in more detail? The link > you provided says very little about it (and the ONLY hit for "implicit > cherrypicking" on Google was your post :-). Yes, but I'm not sure where any more, unfortunately.

Re: Improvements to diff3 (merge) performance

2011-06-13 Thread Morten Kloster
On Sun, Jun 12, 2011 at 9:37 PM, Greg Hudson wrote: > My executive summary of your post is that you want diff3 to try to merge > related, but not identical, changes occuring between a pair of sync > points.  I'm wary about this for two reasons. > > First, the benefit appears to arise chiefly for w

Re: Improvements to diff3 (merge) performance

2011-06-12 Thread Greg Hudson
My executive summary of your post is that you want diff3 to try to merge related, but not identical, changes occuring between a pair of sync points. I'm wary about this for two reasons. First, the benefit appears to arise chiefly for what Bram Cohen calls "implicit cherrypicking" use cases--that

Re: Improvements to diff3 (merge) performance

2011-06-12 Thread Morten Kloster
Ugh - using "---" to separate sections of the post was clearly a really bad idea; sorry about that. :-( Here it is again, in a hopefully more readable format: Hi, I'm not very happy with the current performance of the diff3 algorithm; I think it returns too many and too big conflicts. I have som

Improvements to diff3 (merge) performance

2011-06-12 Thread Morten Kloster
Hi, I'm not very happy with the current performance of the diff3 algorithm; I think it returns too many and too big conflicts. I have some ideas on how to improve it, but I'd like to hear other people's opinions first. Note that the primary purpose is to discuss how we want merge to behave, not wh