On Fri, Oct 21, 2005 at 11:15:51AM +0200, Petr Baudis wrote: > Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter > where "Martin Langhoff (CatalystIT)" <martin@catalyst.net.nz> told me that... > > Almost. No, truly, I'm very impressed with git-merge.sh, which first > > does the simple git-read-tree -m, and it can then try several merger > > scripts to resolve the index. The "smartest" merge resolver we have > > follows renames, but we could have language-specific and > > project-specific resolvers, for instance. > > Yes, following renames is nice. But as long as it is three-way, it > suffers of inherent and rather nasty problems. Well, I'm watching the > weave merge effort and plan to give it a try to port it to GIT when I > have some time. > Which "inherent and rather nasty problems" are you referring to? I do not know of any merge case which is either cleanly merged to the wrong result by git-merge -s recursive, or cleanly merged when it should be a conflict. (At least not if there aren't any directory renames going on) If you know about such an example I would be very interested in taking a look at it. - Fredrik - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.htmlReceived on Mon Oct 24 18:33:47 2005
This archive was generated by hypermail 2.1.8 : 2005-10-24 18:33:51 EST