Re: Expected Behavior?

On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:

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