Re: Google Summer of Code 2009: GIT
- From
- saurabh gupta <saurabhgupta1403@gmail.com>
- Date
- Mar 12, 2009, 12:45 UTC
- Message-ID
- <ab9fa62a0903120545o7e5bc359g7df233b00858869c@mail.gmail.com>
- In-Reply-To
- <7veix33f5e.fsf@gitster.siamese.dyndns.org>
On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 15 quoted lines
> > 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.
> 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.
-- Saurabh Gupta Senior, NSIT,New Delhi, India