Re: Google Summer of Code 2009: GIT

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Wed, 11 Mar 2009, david@lang.hm wrote:

> On Wed, 11 Mar 2009, Johannes Schindelin wrote:
> 
> > On Wed, 11 Mar 2009, david@lang.hm wrote:
> >
> > > On Wed, 11 Mar 2009, Johannes Schindelin wrote:
> > >
> > > > 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.
> >
> > I do not think it makes sense to assume all you have at your hands is 
> > a terminal when you try to resolve a merge conflict in an .svg file.
> 
> I'm not saying that you assume that all you have is a terminal, I'm 
> saying that you _support_ the case that all you have is a terminal.

Sorry, no, the GSoC idea was not about "merge helpers that run also in a 
terminal".  The idea was about "Domain specific merge helpers".

If I can choose, I'd rather have support for one more merge helper, even 
if it is all graphical, than an enhancement to support also a terminal.

While I am dreaming: this is the list of domains _I_ would like to see 
supported: LaTeX, OpenOffice documents, .svg files.

But that is not up to me to decide, just to suggest.

Ciao,
Dscho