On Thu, Mar 12, 2009 at 11:33 PM, <david@xxxxxxx> wrote: > > On Thu, 12 Mar 2009, saurabh gupta wrote: > >> hello, >> >> On Thu, Mar 12, 2009 at 1:51 AM, <david@xxxxxxx> 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. Exactly. This includes the work to modify the xml tags and add contents to represent marker in the best way. -- Saurabh Gupta Senior, NSIT,New Delhi, India -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
