From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Mon, 24 Oct 2005 08:32:16 GMT
Subject: Re: LCA2006 Git/Cogito tutorial
Message-ID: <20051024083216.GA4397@c165.ib.student.liu.se>
In-Reply-To: <20051021091551.GE30889@pasky.or.cz>

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