Re: Google Summer of Code 2009: GIT
- From
Johannes Schindelin <johannes.schindelin@gmx.de>
- Date
- Mar 11, 2009, 14:02 UTC
- Message-ID
- <alpine.DEB.1.00.0903111458340.10498@intel-tinevez-2-302>
- In-Reply-To
- <ab9fa62a0903110655y4a47ccfkde0984ecb46b3307@mail.gmail.com>
Hi,
On Wed, 11 Mar 2009, saurabh gupta wrote:
Show 8 quoted lines
> 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 ;-)
Show 6 quoted lines
> 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