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... Ciao, Dscho -- 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
