On Wed, 11 Mar 2009, saurabh gupta wrote: > On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> 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. > > okay. In that case, if they have a different user interfaces then > separate plug-in would be needed for each of these. May be this will > get more messy. One thing that I think would be good whenever possible is to have the merge program generate a file in the same format which is easily recognizable as having conflict markers. For example, I think it should be possible to show conflicts in the text of office documents by having styles for each side of the merge, and show each side's content in the appropriate style. Then the user opens the document with their choice of office software, finds the things in the conflict styles, and decides what the result should be. Of course, if the two sides conflict over something that isn't text, it gets harder. Also remember that, for a merge, there are two important cases: (1) the two sides changed things that aren't related at all; (2) the two sides changed things that might affect each other. In case (1), the tool should take care of everything automatically and report that it took care of it; in case (2), it should reliably determine that user assistance is required. -Daniel *This .sig left intentionally blank* -- 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
