On Thu, 12 Mar 2009, saurabh gupta wrote:
On Thu, Mar 12, 2009 at 12:59 AM, <david@xxxxxxx> wrote:
On Wed, 11 Mar 2009, saurabh gupta wrote:
On Wed, Mar 11, 2009 at 10:02 PM, <david@xxxxxxx> wrote:
On Wed, 11 Mar 2009, Johannes Schindelin wrote:
Hi,
On Wed, 11 Mar 2009, saurabh gupta wrote:
In case of only a terminal, It would be very difficult to show an OO
document to represent the *diff* output in both text as well in GUI.
For example, to indicate the changes in an OO document, we will have
to change the underlying XML file appropriately to show the markers
signs and other things in the conflict file. Now, if this file is
opened in terminal, it would not be at all comprehensible to see the
differences.
The main thing is that to create *diff* for different file formats, we
will have to write the parser code accordingly.
correct, and in the case of an XML file, the meaningful diff can be
substantially shorter than what a text diff of the two files would be
(whitespace changes that don't matter, even some tag ordering changes may
not matter)
I'm just asking that you don't get so fixated on what can be done in a GUI
that you provide no benifit to people who don't have the GUI
there are a _lot_ of XML based formats out there, having a diff/merge
capability to make dealing with them better than just treating them as text
files would be a _very_ useful thing.
going beyond that and creating the ability to do the markup in
application-specific ways, and present it to the user in a nice GUI would
also be nice, but these are a step up after having the basic XML handling
that isn't specific to a particular application.
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.
besides XML-based formats, a couple other formats that I think would be
useful to be smarter about
unordered config files
files where config options can appear in any order
optionally: comments are similar to whitespace (they can be ignored)
'paragraph' based config files
files where config options are orginized into 'paragraphs' where the
paragraphs can be re-ordered
the definition of what's a paragraph may differ, support having
different defintions
examples:
the git config file has a high level tag that starts on the left margin with the sub-tags indented
the apache config file can have single entries or 'XML like' sections
optionally: comments are similar to whitespace (they can be ignored)
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
