Re: Google Summer of Code 2009: GIT

david@lang.hm writes:

defining terminology that was mentioned before

merge drivers are run by git to do the merges and create the conflict
markers. git already has a 'plug-in architecture' for these drivers
(you can define file types and tell git to use a particular merge
driver for this file type)

merge helpers are run by the users if there is a conflict and make use
of the markers. depending on what you end up using for conflict
markers, you may not need to write a merge helper (for OO, if your
conflict markers are good enough you can use OO to resolve conflicts
easily, no need for a new tool)

Not really.  A merge helper can look at the stages in the index to get the
(original, ours, theirs) tuple and start to work from there (and doing a
helper as a backend of mergetool will be one way to make it easier), and
for such helper the driver does not have to do anything.

with this terminology, you can't do merge helpers without doing the
merge drivers first (what does the helper look for as an indicator of
a conflict?)

The answer to that question is "the index", and your "you can't" is
too strong.

I agree with you that the original "editor" for the specific type of
document (e.g. OOo, inkskape, ...) can be used to fix things up if a
driver can leave conflict markers in such a way that the helper does not
have to do three-file merge, and that would be a nice thing to have.  But
for a helper that can do a real three-file merge (and in this thread I
think somebody said OOo can do that), then it is Ok for a driver to punt.

But even then, *if* there is a driver *and* it can do trivial merges
cleanly and safely, it would be a huge productivity win, as you do not
have to run a helper every time you see two branching touching the same
document even they did so to edit totally unrelated parts of it.