Re: Google Summer of Code 2009: GIT

[Junio C Hamano <gitster@pobox.com>]

david@lang.hm writes:

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