Re: Google Summer of Code 2009: GIT

[saurabh gupta <saurabhgupta1403@gmail.com>]

On Fri, Mar 13, 2009 at 12:59 AM,  <david@lang.hm> 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