From: david@lang.hm Date: Thu, 12 Mar 2009 18:03:47 GMT Subject: Re: Google Summer of Code 2009: GIT Message-ID: In-Reply-To: On Thu, 12 Mar 2009, saurabh gupta wrote: > hello, > > On Thu, Mar 12, 2009 at 1:51 AM, wrote: >> >>> Yes, but the thing is that the underlying codes and method will be >>> different for GUI part and terminal part to make it readable and >>> understandable. Like for OO Documents, if we aim to show the *diff* >>> output in the Office tool, then we have to change the xml file >>> accordingly. But the same xml file when used with terminal only, the >>> *diff* output is not clear. >>> >>> As Johannes said in above post that for OO documents, while showing >>> the *diff* result, no xml data should be shown. >> >> in part we are talking about different aspects of things, and we were all >> wrong. >> >> see the e-mail a little bit ago by Junio >> >> there are two types of helpers that can be written >> >> 1. a low-level part that does the simple merges automaticaly and leaves >> behind appropriate conflict markers when it can't >> >> there is no GUI involved with this. >> >> what 'appropriate conflict markers' are can vary from XML file to XML file >> >> >> 2. after a conflict has taken place, a helper to work with the user to >> resolve the conflict >> >> this can have a GUI and/or a text UI and is tied to the 'appropriate >> conflict markers' as defined in #1, and can be _very_ tightly coupled to the >> specific use of the XML file. >> >> I think it's very important to have a text UI tool that can be used for the >> conflict resolution step as well as supporting GUI tools. > > All right. What I can understand from the current situation is that > for merging and marking conflicts in xml (for example) files has > following things to do. > > One, if the markers are put in the xml files like that of a text file, > one can see the difference using a text editor or a terminal. But if > the same xml file is to be opened in another editor which expects a > valid xml (as clearly mentioned on the wiki ideas for GIT), then a > merge helper is needed. > > But if the conflict markers are put in a way to make the xml file > still valid which can be then opened in the appropriate editor, then > the marking will be different. The merge driver has to produce the > conflicted merged file in a manner which is still a valid xml file and > user has the choice to open it in his own editor to resolve the > conflicts. exactly. and how you mark the conflict to have it be valid XML is going to depend on details of the type of file. there are probably a few basic methods that will work the vast majority of the time, but with some details needing to be configurable. for example, if the XML document is a ODF document, it may be possible to add 'revision' tags around the conflict that are already understood by the editor. David Lang