Re: LCA2006 Git/Cogito tutorial

From: Petr Baudis <pasky@suse.cz>
Date: Oct 21, 2005, 09:15 UTC
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)" <martin@catalyst.net.nz> told me that...

Show 5 quoted lines

> 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.

Show 12 quoted lines

> 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.