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.
David Lang
--
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
