Linus Torvalds wrote: > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
