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