From: Petr Baudis Date: Fri, 21 Oct 2005 09:15:51 GMT Subject: Re: LCA2006 Git/Cogito tutorial Message-ID: <20051021091551.GE30889@pasky.or.cz> In-Reply-To: <4358597A.6000306@catalyst.net.nz> Dear diary, on Fri, Oct 21, 2005 at 04:59:06AM CEST, I got a letter where "Martin Langhoff (CatalystIT)" 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. > If you combine the coolness of git-merge.sh with the fact that cg-merge > right now is buggy[*]... I'm starting to rely on doing cg-fetch and > running git-merge.sh by hand. > > * I just merged your latest fixes, knowing that they'd conflict on > cg-fetch, but the merge didn't say a thing a bout cg-fetch, and only > complained like this: > > MERGE ERROR: : Not handling case -> -> > > But there were no conflicts at all in the tree! It seems to be that it's > dropping the upstream changes it doesn't like. There was a bug in argument parsing of cg-Xmergefile, already fixed now. Well, it's true that cg-Xmergefile still does not handle all merge cases, but it certainly will not be silent about it, at least. ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.