Hi, On Wed, 11 Mar 2009, david@xxxxxxx wrote: > On Wed, 11 Mar 2009, Johannes Schindelin wrote: > > > On Wed, 11 Mar 2009, david@xxxxxxx 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 -- 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
