david@xxxxxxx 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
