Re: Google Summer of Code 2009: GIT

From: david@lang.hm <david@lang.hm>
Date: Mar 12, 2009, 18:00 UTC
Message-ID: <alpine.DEB.1.10.0903121052310.16753@asgard.lang.hm>
In-Reply-To: <ab9fa62a0903120545o7e5bc359g7df233b00858869c@mail.gmail.com>

On Thu, 12 Mar 2009, saurabh gupta wrote:

Show 40 quoted lines

> On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> 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.
>
> If I am not wrong, then for merging two xml files, if we use a simple
> xdl merge driver then it will mark the conflicts in the normal way as
> it does for simple text files. As far as I can understand, the
> following things are supposed to be aimed here taking an example of
> xml file:
>
>
> =>Merging of two xml files
>
> => existing merge driver (like xdl) is called which marks the
> conflicts points just like a normal text file.
>
> => the conflicted file can be read through a text terminal and
> conflicted lines can be seen.
>
> => suppose the xml file is from the domain of OO document. Then, a
> merge helper for OO xml type file is called which takes input as the
> conflicted file produced by xdl driver.
>
> => The merge helper creates a new file or changes the input file to
> make it a valid xml file so that it can be opened in OpenOffice and
> user can see the markers like "====" or "<<<<<"  in an appropriate
> manner and can resolve the file manually.

with XML files it's possible to be symanticly identical, but not identical as far as a text merge driver is concerned.

for example, the following two tags are identical in meaning, but would show up as different (and therefor in conflict) in a text merge

in many instances (such as config files), the order of items doesn't change the meaning. so the following two items would be identical

<tag1>
   stuff
</tag1>
<tag2>
   more stuff
</tag2>

vs

<tag2>
   more stuff
</tag2>
<tag1>
   stuff>
</tag1>

in addition whitespace may or may not be relavent (depending on how the XML is used) so the following may also be identical

<tag>stuff<tag>

vs <tag> stuff </tag>

a good XML merge driver would have options that you could set for a particular file type to know about these sorts of things.

Show 8 quoted lines

>>  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.
>
> I think you mean to say that in case, there is a conflict and the
> changes don't overlap, then merge driver leaves the file as it is and
> the merge helper will handle the file.

if there is a conflict it should be because the changes do overlap. if they don't overlap why is it a conflict?

David Lang