Re: Google Summer of Code 2009: GIT

On Fri, Mar 13, 2009 at 12:59 AM,  [off-list ref] wrote:

On Fri, 13 Mar 2009, saurabh gupta wrote:

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)


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

I believe that there is a lot of potential for a configurable merge driver
to support many similar formats.

using the example of XML-based files, configurable options could include

1. is the file stored compressed or not

2. does the order of the tags matter

3. does whitespace matter

 note: #2 and #3 may boil down to 'is this a document with XML markup, or
are the XML tags the primary content'

4. how is the conflict marked

4a. wrap the conflicting tags in a set of tags that look like _

4b. if the conflict is in the content, not the tags, modify it similar to
what we do with text today.

 note: this still requires the new driver to decide if there is a conflict
or not

4c. other (potentially including calling out to other code for more drastic
restructuring)


with a merge driver along these lines you can handle many different types of
XML documents.

with SVG you may be able to put the offending tags in different layers

with OO you may be able to put in tags that indicate a merge conflict in a
way that OO will directly handle

etc.

in many cases you may not even need to create a merge helper or library for
other software you use. you just need to figure out what sort of
manipulation would need to be done to to file to mark the conflict in a way
that existing applications can understand.

Very well described, David. I agree with you and providing these merge
options to the user, merge drivers can do the work and mark the
conflicts according to the option. The work to do is to modify the
merge driver. I think in this way, even people who have only a
terminal can also gain from it. They can choose the apt option to see
the conflict markers in their way. So, the aim is to make merge driver
configurable and create the merged/conflicted file according to the
options.


-- 
Saurabh Gupta
Senior,
NSIT,New Delhi, India