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:
What I think is to implement file formats other than text like that
written on wiki i.e. latex, xml, or even any database file (db file).
Another idea (although it can be weired also) is to implement the new
file formats in the plug-in formats. For example, to incorporate the
merger engine for a new file format, a plug-in is created and can be
integrated with the present merger in the git. However, I am not sure
how much valid is this idea to make the present merger in git to be
compatible with the plug-ins for enabling newer file formats.
I am not sure that a plugin structure is needed. Take, for example, three
different .xml based formats: OpenOffice documents, .svg files and Ant
build.xml files. They need very different user interfaces.
I am thinking of using gtk+ libraries to implement the GUI part (I am
quite comfortable with gtk+).
I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based
stuff ;-)
However, I think in merging and notifying about the conflicts in the xml
files, other things can also be put forward. Like the GUI will show the
number of tags differing and what are the new tags added and even if any
tag is renamed with the content unchanged. If possible, how about
showing a tree like structure (just like DOM model) to compare (or diff)
the two xml files.
This is a little bit too low-level for my liking. Taking the OpenOffice
example again, the GUI should not expose XML at all...
don't assume that you have a GUI just to handle a filetype. if you have one,
good, make use of it. but have a fallback for how to deal with things if all
you have is a text terminal.
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.
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
