Re: inexplicable failure to merge recursively across cherry-picks

From: Sam Vilain <sam@vilain.net>
Date: Oct 11, 2007, 21:51 UTC
Message-ID: <470E9AD5.2090002@vilain.net>
In-Reply-To: <alpine.LFD.0.999.0710100808150.3838@woody.linux-foundation.org>

Linus Torvalds wrote:

Show 7 quoted lines

> So git doesn't try to avoid conflicts per se: the merge strategies are 
> fundamentally pretty simple (rename detection and the whole "recursive 
> merge" thing may not be simple code, but the concepts are pretty 
> straightforward), and they handle all the really *obvious* cases, but at 
> the same time, I feel strongly that anything even half-way subtle should 
> not be left to the SCM - the SCM should show it and make it really easy 
> for the user to then fix it up.

This is true. However I think there are some obvious places for improvement that does look at the file history, when the regular algorithm fails;

1. do a --cherry-pick rev-list on just the file being merged and see if
all the changes on one side disappear, in which case just take the result.

2. see if the files were identical at some point, in which case use a
new merge base for that file based on the changes since that revision.

I actually thought #2 was already the way recursive worked!

Sam.