From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Wed, 09 Nov 2005 23:04:11 GMT
Subject: Re: Expected Behavior?
Message-ID: <46a038f90511091504l7218df18k251bec75491891e9@mail.gmail.com>
In-Reply-To: <20051109112452.GD30496@pasky.or.cz>

On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> The world would be so much better if there would be just a _single_
> per-file automerger instead of three right now...

I don't quite agree with this. The multi-merger mechanism is something
(relatively) unique and powerful in GIT. Having fast+stupid, with
fallback to slow+smart is an excellent strategy, and having the
mechanism in place means that if someone is crazy enough to write a
smarter merge script for a language or a particular project (say, to
ease the transition to a new directory layout) it is entirely
possible.

In the end, merges are tricky and need to be controlled by the end
user. We can help this giving the user good control and good
visibility of what decisions the merger is taking.

> I'm planning to feed back the automerger stuff from Cogito to GIT like I
> already did once.

I use both mergers (cg and git) and I'd really _really_ like to turn
cg-merge into a wrapper for git-merge. The cg merger does the basics:
trivial merge, fast forwards and diff3 merges. Adding the rest is
_hard_ and debugging/auditing it is even harder. IMHO, having strong,
high quality mergers is a must, and it's a complex enough space that a
porcelain should align itself with git so we get a strong set of
mergers done in a way that all porcelains can hook into.

I made an initial half-attempt but it's trickier that I had expected
because cg-merge relies on cg-commit to wrap up, marke the index as
resolved, and commit, and I'm not entirely sure of how that works in
detail. My changes were going in the direction of breaking the current
usage patterns, so it was a no-go really.

cheers,


martin