On Thu, 12 Mar 2009, saurabh gupta wrote:
On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@xxxxxxxxx> 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
<tag attr1='foo' attr2='bar' />
<tag attr2='bar' attr1='foo' />
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.
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
