Re: Google Summer of Code 2009: GIT

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 11, 2009, 21:47 UTC
Message-ID: <7veix33f5e.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.1.10.0903111401520.16753@asgard.lang.hm>

david@lang.hm writes:

Show 15 quoted lines

>>> there are two types of helpers that can be written
>>>
>>> 1. a low-level part that does the simple merges automaticaly and leaves
>>>    behind appropriate conflict markers when it can't
>>>
>>> 2. after a conflict has taken place, a helper to work with the user to
>>>    resolve the conflict
> ...
> secondly, I somewhat disagree with you. #1 is needed for any new
> formats that are goning to be handled, but #2 may not be.
>
> take the case of OO documents, you may not need to write a conflict
> resolver helper. the 'appropriate conflict markers' may be something
> that shows up in your normal OO document editor similar to how the
> ====> shows up in a text editor for text conflicts

You can cut it both ways. For an OO document, you do not necessarily need any file-level merger at the driver level, but just let the "binary" driver declare conflicts and punt. A merge helper can do all the work starting from the "original, ours and theirs" that are not smudged with conflict markers.

Between these two extremes, the discussion from other people in the thread seemed to all focus too heavily on the "driver punts" approach, forgetting that mergetool is useful only because most of the time we do not have to even use it, thanks to the fact that "xdl" driver works reasonably well for most trivial cases where branches being merged stayed away from each other, which is the majority case. It is a huge win from the productivity point of view, and many people might be unaware of it because it is so invisible.

Handling trivial cases safely and automatically at the driver level, if you can figure out how, lets the user focus on hard cases that needs manual intervention, and "merge helper" is about helping that manual intervention step.

Being aware of these two distinct layers allows you to realize that there is a third possibility. The driver could notice the cases it can resolve cleanly and return a cleanly merged result. When it cannot autoresolve, but there is no way to "mark" a tentative result with conflict markers, it can do the same thing as the "binary" driver and let the mergetool backend handle the "driver punted" case.