{"thread":{"id":"18261","subject":"Google Summer of Code 2009: GIT","startedAt":"2009-03-11T04:52:03Z","lastAt":"2009-03-21T23:53:36Z","messageCount":76,"participants":["Saurabh Gupta","Daniel Barkalow","David Symonds","saurabh gupta","Johannes Schindelin","Rogan Dawes","david@lang.hm","Junio C Hamano","thestar@fussycoder.id.au","Michael J Gruber","Caleb Cushing"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"107642","messageId":"49B74373.3090609@gmail.com","threadId":"18261","inReplyTo":null,"subject":"Google Summer of Code 2009: GIT","fromName":"Saurabh Gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T04:52:03Z","receivedAt":"2009-03-11T04:52:03Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"hello everyone,\n\n/*First, a brief introduction about me: */\nI am Saurabh Gupta from India. I am a senior engineering student. I\nhave been working for open source projects for a long time and I was a\n*GSoC student in 2008* where I successfully completed my project under\nthe organization Openmoko (www.openmoko.org\n<http://www.openmoko.org/>). In 2008 winters, I had my internship at\n*Adobe Inc.* where I worked on the package  management system using\nC++ and sqlite library. I have a long experience in programming in C,\nC++,  Python and other languages. Currently, my final year project at\nuniversity is about the automatic data logging system in which I am\nworking upon socket programming in C, C++,   MYSQL and setting up an\nintra-college website using LAMP. I am a user of svn extensively and\nuse git sometimes.\n\n\n/*About GSoC GIT ideas;\n*/Here are the ideas which I found to be interested in. Although, I\nwould like to discuss any other idea than these in GIT organization.\n\n*1) Domain specific merge helpers*\nIntelligence in the merger can be put which modifies the source file\naccording the format. Different file formats can be put in the merger\nto support.\n\n\nI am looking forward to get feedback and suggestions for this and to\ndiscuss the ideas. I would like to contribute GIT this summer if I get\na chance through GSoC. If not, then still, I would remain in contact\nwith the community to contribute in the best possible manner I can.\n"},{"id":"107647","messageId":"alpine.LNX.1.00.0903110147270.19665@iabervon.org","threadId":"18261","inReplyTo":"49B74373.3090609@gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-11T05:56:30Z","receivedAt":"2009-03-11T05:56:30Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 Mar 2009, Saurabh Gupta wrote:\n\n> hello everyone,\n> \n> /*First, a brief introduction about me: */\n> I am Saurabh Gupta from India. I am a senior engineering student. I\n> have been working for open source projects for a long time and I was a\n> *GSoC student in 2008* where I successfully completed my project under\n> the organization Openmoko (www.openmoko.org\n> <http://www.openmoko.org/>). In 2008 winters, I had my internship at\n> *Adobe Inc.* where I worked on the package  management system using\n> C++ and sqlite library. I have a long experience in programming in C,\n> C++,  Python and other languages. Currently, my final year project at\n> university is about the automatic data logging system in which I am\n> working upon socket programming in C, C++,   MYSQL and setting up an\n> intra-college website using LAMP. I am a user of svn extensively and\n> use git sometimes.\n> \n> \n> /*About GSoC GIT ideas;\n> */Here are the ideas which I found to be interested in. Although, I\n> would like to discuss any other idea than these in GIT organization.\n> \n> *1) Domain specific merge helpers*\n> Intelligence in the merger can be put which modifies the source file\n> according the format. Different file formats can be put in the merger\n> to support.\n\nThis is something I've thought would be really handy for making git more \nwidely useful. The hard part, of course, is coming up with useful \nalternative merge algorithms which work for formats that the usual merge \ndoesn't handle. The infrastructure is mostly there (git supports declaring \nthe types of files), but there's no point in support for running a \ntype-specific merger until there are actually type-specific mergers to \nrun.\n\nDo you have ideas on what formats you'd try to merge, and how?\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"107654","messageId":"ee77f5c20903110159l1cda4c3dnc9588c1352905932@mail.gmail.com","threadId":"18261","inReplyTo":"49B74373.3090609@gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2009-03-11T08:59:03Z","receivedAt":"2009-03-11T08:59:03Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Wed, Mar 11, 2009 at 3:52 PM, Saurabh Gupta\n<saurabhgupta1403@gmail.com> wrote:\n\n> *1) Domain specific merge helpers*\n> Intelligence in the merger can be put which modifies the source file\n> according the format. Different file formats can be put in the merger\n> to support.\n\nI don't think that's Git specific, though it still might be reasonable\nto be done as a Git GSoC project. I'm sure other VCSs would find that\nuseful, and even folk who aren't using VCSs might benefit from it.\n\n\nDave.\n"},{"id":"107656","messageId":"ab9fa62a0903110202y743767c6v372bedf9e1b9a11@mail.gmail.com","threadId":"18261","inReplyTo":"ee77f5c20903110159l1cda4c3dnc9588c1352905932@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T09:02:34Z","receivedAt":"2009-03-11T09:02:34Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 2:29 PM, David Symonds <dsymonds@gmail.com> wrote:\n>\n> On Wed, Mar 11, 2009 at 3:52 PM, Saurabh Gupta\n> <saurabhgupta1403@gmail.com> wrote:\n>\n> > *1) Domain specific merge helpers*\n> > Intelligence in the merger can be put which modifies the source file\n> > according the format. Different file formats can be put in the merger\n> > to support.\n>\n> I don't think that's Git specific, though it still might be reasonable\n> to be done as a Git GSoC project. I'm sure other VCSs would find that\n> useful, and even folk who aren't using VCSs might benefit from it.\n\nAll right.\nCan you suggest me another idea or any aim which GIT will mostly be\ninterested in. I am also looking over other ideas and areas where more\nimprovement can be put.\n\nThanks...\n\n\n>\n> Dave.\n\n\n\n--\nSaurabh Gupta\nSenior,\nElectronics and Communication Engg.\nNSIT,New Delhi, India\n"},{"id":"107657","messageId":"ab9fa62a0903110204o5b436a58v848905319e579753@mail.gmail.com","threadId":"18261","inReplyTo":"ab9fa62a0903102317l3a7322f7w5e4d9ba0e02af37b@mail.gmail.com","subject":"Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T09:04:09Z","receivedAt":"2009-03-11T09:04:09Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"hello,\n\nOn Wed, Mar 11, 2009 at 11:26 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:\n>\n> On Wed, 11 Mar 2009, Saurabh Gupta wrote:\n>\n> >\n> > /*About GSoC GIT ideas;\n> > */Here are the ideas which I found to be interested in. Although, I\n> > would like to discuss any other idea than these in GIT organization.\n> >\n> > *1) Domain specific merge helpers*\n> > Intelligence in the merger can be put which modifies the source file\n> > according the format. Different file formats can be put in the merger\n> > to support.\n>\n> This is something I've thought would be really handy for making git more\n> widely useful. The hard part, of course, is coming up with useful\n> alternative merge algorithms which work for formats that the usual merge\n> doesn't handle. The infrastructure is mostly there (git supports declaring\n> the types of files), but there's no point in support for running a\n> type-specific merger until there are actually type-specific mergers to\n> run.\n>\n> Do you have ideas on what formats you'd try to merge, and how?\n\nWell, What I think is to implement file formats other than text like\nthat written on wiki i.e. latex, xml, or even any database file (db\nfile).  Another idea (although it can be weired also) is to implement\nthe new file formats in the plug-in formats. For example, to\nincorporate the merger engine for a new file format, a plug-in is\ncreated and can be integrated with the present merger in the git.\nHowever, I am not sure how much valid is this idea to make the present\nmerger in git to be compatible with the plug-ins for enabling newer\nfile formats.\n\nAny new idea or suggestions are welcome.\n\n\n\n-- \nSaurabh Gupta\nSenior,\nElectronics and Communication Engg.\nNSIT,New Delhi, India\n"},{"id":"107674","messageId":"ee77f5c20903110455p6926b580i8c8e92b051328d18@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111254410.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"David Symonds","fromEmail":"dsymonds@gmail.com","sentAt":"2009-03-11T11:55:04Z","receivedAt":"2009-03-11T11:55:04Z","isPatch":false,"sender":{"key":"dsymonds@gmail.com","avatar":"https://gravatar.com/avatar/b22f5051cbfc11836e36cf7a690e6cde4e225d835e13295ff98d15c7a9ee3c0f?d=mp&s=160"},"body":"On Wed, Mar 11, 2009 at 10:55 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n\n> It has been suggested on the GSoC mentor list, and IMHO Git is as good as\n> any organization to host that project.\n\nYeah, I think Git would be a good host for such a project. I'd still\nlike to see it VCS-neutral, though.\n\n\nDave.\n"},{"id":"107673","messageId":"alpine.DEB.1.00.0903111254410.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"ee77f5c20903110159l1cda4c3dnc9588c1352905932@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T11:55:38Z","receivedAt":"2009-03-11T11:55:38Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, David Symonds wrote:\n\n> On Wed, Mar 11, 2009 at 3:52 PM, Saurabh Gupta\n> <saurabhgupta1403@gmail.com> wrote:\n> \n> > *1) Domain specific merge helpers* Intelligence in the merger can be \n> > put which modifies the source file according the format. Different \n> > file formats can be put in the merger to support.\n> \n> I don't think that's Git specific, though it still might be reasonable \n> to be done as a Git GSoC project. I'm sure other VCSs would find that \n> useful, and even folk who aren't using VCSs might benefit from it.\n\nIt has been suggested on the GSoC mentor list, and IMHO Git is as good as \nany organization to host that project.\n\nCiao,\nDscho\n"},{"id":"107675","messageId":"alpine.DEB.1.00.0903111255470.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"49B74373.3090609@gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T11:58:45Z","receivedAt":"2009-03-11T11:58:45Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nWelcome, Saurabh!\n\nOn Wed, 11 Mar 2009, Saurabh Gupta wrote:\n\n> /*About GSoC GIT ideas; */Here are the ideas which I found to be \n> interested in. Although, I would like to discuss any other idea than \n> these in GIT organization.\n> \n> *1) Domain specific merge helpers* Intelligence in the merger can be put \n> which modifies the source file according the format. Different file \n> formats can be put in the merger to support.\n\nYou said that you are interested in this project, but from your mails I do \nnot see what are the specific reasons why.\n\nIMHO this project can only fly if you have a specific file format that you \nabsolutely want to be able to merge; otherwise, it will be an uphill \nfight.\n\nPersonally, I would _love_ to see a good graphical tool (maybe written \nin Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not \nhave the time...\n\nCiao,\nDscho\n"},{"id":"107680","messageId":"ab9fa62a0903110511u63e7d46dr3bb783ee891ca4ae@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111255470.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T12:11:36Z","receivedAt":"2009-03-11T12:11:36Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n>\n> Hi,\n>\n> Welcome, Saurabh!\n>\n> On Wed, 11 Mar 2009, Saurabh Gupta wrote:\n>\n> > /*About GSoC GIT ideas; */Here are the ideas which I found to be\n> > interested in. Although, I would like to discuss any other idea than\n> > these in GIT organization.\n> >\n> > *1) Domain specific merge helpers* Intelligence in the merger can be put\n> > which modifies the source file according the format. Different file\n> > formats can be put in the merger to support.\n>\n> You said that you are interested in this project, but from your mails I do\n> not see what are the specific reasons why.\n>\n\nAll right. May be I lacked in my mail to specify the reason for my\ninterest. The reason is that from my past experience, I got the notion\nthat this project is according to my interest and is doable in the\nthree months time period.\nAnother reason is that I have been using the versioning tools like svn\nand now perforce for a long time and this added up to my interest.\n\n\n> IMHO this project can only fly if you have a specific file format that you\n> absolutely want to be able to merge; otherwise, it will be an uphill\n> fight.\n>\n\nWell, as suggested on the wiki, I would like to work on the xml file\nformats as I have quite experience of working with xml files and\nparsing them using msxml and nsxml libraries and some of personal\nwrappers.\n\nHow about my idea of making the support of new file formats in the\nplug-ins (suggested in my last post). I would like to discuss more on\nthis and any new suggestions or methods are welcome.\n\n> Personally, I would _love_ to see a good graphical tool (maybe written\n> in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not\n> have the time...\n\nOk. What I am thinking is to implement something  like that of\ngraphical *diff* command output but in these special file formats, it\nought to have intelligence to bring out the difference of two files\n(like latex or xml) in a readable manner. For example, in case of xml\nfiles, if one file contains an inner tag block , then merger GUI\nshould notify the user in a readable manner about this added tag\nrather than only the difference in lines.\n\n>\n> Ciao,\n> Dscho\n>\n\nRegards...\n\n--\nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107683","messageId":"alpine.DEB.1.00.0903111351280.10498@intel-tinevez-2-302","threadId":"18261","inReplyTo":"ee77f5c20903110455p6926b580i8c8e92b051328d18@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T12:52:23Z","receivedAt":"2009-03-11T12:52:23Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, David Symonds wrote:\n\n> On Wed, Mar 11, 2009 at 10:55 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> \n> > It has been suggested on the GSoC mentor list, and IMHO Git is as good \n> > as any organization to host that project.\n> \n> Yeah, I think Git would be a good host for such a project. I'd still\n> like to see it VCS-neutral, though.\n\nYeah, I cannot see this begin Git-specific, either.  But it may be \nintegrated with Git so that it works best using Git...\n\nCiao,\nDscho\n"},{"id":"107685","messageId":"alpine.DEB.1.00.0903111353340.10498@intel-tinevez-2-302","threadId":"18261","inReplyTo":"ab9fa62a0903110511u63e7d46dr3bb783ee891ca4ae@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T12:58:10Z","receivedAt":"2009-03-11T12:58:10Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, saurabh gupta wrote:\n\n> On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n>\n> > On Wed, 11 Mar 2009, Saurabh Gupta wrote:\n> >\n> > > /*About GSoC GIT ideas; */Here are the ideas which I found to be \n> > > interested in. Although, I would like to discuss any other idea than \n> > > these in GIT organization.\n> > >\n> > > *1) Domain specific merge helpers* Intelligence in the merger can be \n> > > put which modifies the source file according the format. Different \n> > > file formats can be put in the merger to support.\n> >\n> > You said that you are interested in this project, but from your mails \n> > I do not see what are the specific reasons why.\n> \n> All right. May be I lacked in my mail to specify the reason for my \n> interest.\n\nOh, sorry, I did not mean to imply any offense...\n\n> The reason is that from my past experience, I got the notion that this \n> project is according to my interest and is doable in the three months \n> time period.\n>\n> Another reason is that I have been using the versioning tools like svn \n> and now perforce for a long time and this added up to my interest.\n\nSounds good!\n\n> > IMHO this project can only fly if you have a specific file format that \n> > you absolutely want to be able to merge; otherwise, it will be an \n> > uphill fight.\n> \n> Well, as suggested on the wiki, I would like to work on the xml file \n> formats as I have quite experience of working with xml files and parsing \n> them using msxml and nsxml libraries and some of personal wrappers.\n\nAs I am known to not exactly like Microsoft's products, if you wanted to \nhave me as a mentor, you'd need to use Open Source libraries to do the \nparsing.\n\n> How about my idea of making the support of new file formats in the \n> plug-ins (suggested in my last post).\n\nSorry, I missed that idea.  Could you describe it again?\n\n> > Personally, I would _love_ to see a good graphical tool (maybe written \n> > in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not \n> > have the time...\n> \n> Ok. What I am thinking is to implement something  like that of\n> graphical *diff* command output but in these special file formats, it\n> ought to have intelligence to bring out the difference of two files\n> (like latex or xml) in a readable manner. For example, in case of xml\n> files, if one file contains an inner tag block , then merger GUI\n> should notify the user in a readable manner about this added tag\n> rather than only the difference in lines.\n\nA diff would be a first step, but the real issue are the merge helpers.  \nAnd they need first and foremost a thought-through user interface design.  \nThe technical issues are all solveable, I am sure.\n\nCiao,\nDscho\n"},{"id":"107690","messageId":"ab9fa62a0903110655y4a47ccfkde0984ecb46b3307@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111353340.10498@intel-tinevez-2-302","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T13:55:54Z","receivedAt":"2009-03-11T13:55:54Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 6:28 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>\n>> On Wed, Mar 11, 2009 at 5:28 PM, Johannes Schindelin\n>> <Johannes.Schindelin@gmx.de> wrote:\n>>\n>> > On Wed, 11 Mar 2009, Saurabh Gupta wrote:\n>> >\n>> > > /*About GSoC GIT ideas; */Here are the ideas which I found to be\n>> > > interested in. Although, I would like to discuss any other idea than\n>> > > these in GIT organization.\n>> > >\n>> > > *1) Domain specific merge helpers* Intelligence in the merger can be\n>> > > put which modifies the source file according the format. Different\n>> > > file formats can be put in the merger to support.\n>> >\n>> > You said that you are interested in this project, but from your mails\n>> > I do not see what are the specific reasons why.\n>>\n>> All right. May be I lacked in my mail to specify the reason for my\n>> interest.\n>\n> Oh, sorry, I did not mean to imply any offense...\n\nNo, I didn;t mean that either too :-D\n\n>\n>> The reason is that from my past experience, I got the notion that this\n>> project is according to my interest and is doable in the three months\n>> time period.\n>>\n>> Another reason is that I have been using the versioning tools like svn\n>> and now perforce for a long time and this added up to my interest.\n>\n> Sounds good!\n>\n>> > IMHO this project can only fly if you have a specific file format that\n>> > you absolutely want to be able to merge; otherwise, it will be an\n>> > uphill fight.\n>>\n>> Well, as suggested on the wiki, I would like to work on the xml file\n>> formats as I have quite experience of working with xml files and parsing\n>> them using msxml and nsxml libraries and some of personal wrappers.\n>\n> As I am known to not exactly like Microsoft's products, if you wanted to\n> have me as a mentor, you'd need to use Open Source libraries to do the\n> parsing.\n\nYeah, of course. I mentioned msxml and nsxml just to indicate that I\nam comfortable with the xml parsing. I will, no doubt, go for open\nsource libraries to parse xml and write or reuse some of my own\nwrappers to parse xml.\n\n\n\n>> How about my idea of making the support of new file formats in the\n>> plug-ins (suggested in my last post).\n>\n> Sorry, I missed that idea.  Could you describe it again?\n>\n\nAll right. This is the quote which I said in my last posts.\n\n=>What I think is to implement file formats other than text like\nthat written on wiki i.e. latex, xml, or even any database file (db\nfile).  Another idea (although it can be weired also) is to implement\nthe new file formats in the plug-in formats. For example, to\nincorporate the merger engine for a new file format, a plug-in is\ncreated and can be integrated with the present merger in the git.\nHowever, I am not sure how much valid is this idea to make the present\nmerger in git to be compatible with the plug-ins for enabling newer\nfile formats.\n\n\n>> > Personally, I would _love_ to see a good graphical tool (maybe written\n>> > in Tcl/Tk) to help merging conflicts in LaTeX files, but I just do not\n>> > have the time...\n>>\n>> Ok. What I am thinking is to implement something  like that of\n>> graphical *diff* command output but in these special file formats, it\n>> ought to have intelligence to bring out the difference of two files\n>> (like latex or xml) in a readable manner. For example, in case of xml\n>> files, if one file contains an inner tag block , then merger GUI\n>> should notify the user in a readable manner about this added tag\n>> rather than only the difference in lines.\n>\n> A diff would be a first step, but the real issue are the merge helpers.\n> And they need first and foremost a thought-through user interface design.\n> The technical issues are all solveable, I am sure.\n\nI got your point. I am thinking of using gtk+ libraries to implement\nthe GUI part (I am quite comfortable with gtk+). However, I think in\nmerging and notifying about the conflicts in the xml files, other\nthings can also be put forward. Like the GUI will show the number of\ntags differing and what are the new tags added and even if any tag is\nrenamed with the content unchanged. If possible, how about showing a\ntree like structure (just like DOM model) to compare (or diff) the two\nxml files.\n\n\n> Ciao,\n> Dscho\n>\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107691","messageId":"alpine.DEB.1.00.0903111458340.10498@intel-tinevez-2-302","threadId":"18261","inReplyTo":"ab9fa62a0903110655y4a47ccfkde0984ecb46b3307@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T14:02:00Z","receivedAt":"2009-03-11T14:02:00Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, saurabh gupta wrote:\n\n> What I think is to implement file formats other than text like that \n> written on wiki i.e. latex, xml, or even any database file (db file).  \n> Another idea (although it can be weired also) is to implement the new \n> file formats in the plug-in formats. For example, to incorporate the \n> merger engine for a new file format, a plug-in is created and can be \n> integrated with the present merger in the git. However, I am not sure \n> how much valid is this idea to make the present merger in git to be \n> compatible with the plug-ins for enabling newer file formats.\n\nI am not sure that a plugin structure is needed.  Take, for example, three \ndifferent .xml based formats: OpenOffice documents, .svg files and Ant \nbuild.xml files.  They need very different user interfaces.\n\n> I am thinking of using gtk+ libraries to implement the GUI part (I am \n> quite comfortable with gtk+).\n\nI mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based \nstuff ;-)\n\n> However, I think in merging and notifying about the conflicts in the xml \n> files, other things can also be put forward. Like the GUI will show the \n> number of tags differing and what are the new tags added and even if any \n> tag is renamed with the content unchanged. If possible, how about \n> showing a tree like structure (just like DOM model) to compare (or diff) \n> the two xml files.\n\nThis is a little bit too low-level for my liking.  Taking the OpenOffice \nexample again, the GUI should not expose XML at all...\n\nCiao,\nDscho\n"},{"id":"107692","messageId":"ab9fa62a0903110713k2a21cefbj1e7cd3c126aca8f9@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111458340.10498@intel-tinevez-2-302","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T14:13:50Z","receivedAt":"2009-03-11T14:13:50Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>\n>> What I think is to implement file formats other than text like that\n>> written on wiki i.e. latex, xml, or even any database file (db file).\n>> Another idea (although it can be weired also) is to implement the new\n>> file formats in the plug-in formats. For example, to incorporate the\n>> merger engine for a new file format, a plug-in is created and can be\n>> integrated with the present merger in the git. However, I am not sure\n>> how much valid is this idea to make the present merger in git to be\n>> compatible with the plug-ins for enabling newer file formats.\n>\n> I am not sure that a plugin structure is needed.  Take, for example, three\n> different .xml based formats: OpenOffice documents, .svg files and Ant\n> build.xml files.  They need very different user interfaces.\n\nokay. In that case, if they have  a different user interfaces then\nseparate plug-in would be needed for each of these. May be this will\nget more messy.\n\n>\n>> I am thinking of using gtk+ libraries to implement the GUI part (I am\n>> quite comfortable with gtk+).\n>\n> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based\n> stuff ;-)\n\nAll right. We can think over this issue. Being honest, I have not\nworked on Tcl/Tk yet but I have no problem in learning it and I am\nsure that I will get my hands on Tcl/Tk within no time.\n\n>> However, I think in merging and notifying about the conflicts in the xml\n>> files, other things can also be put forward. Like the GUI will show the\n>> number of tags differing and what are the new tags added and even if any\n>> tag is renamed with the content unchanged. If possible, how about\n>> showing a tree like structure (just like DOM model) to compare (or diff)\n>> the two xml files.\n>\n> This is a little bit too low-level for my liking.  Taking the OpenOffice\n> example again, the GUI should not expose XML at all...\n\nhmmmm.....I think I get your point somewhat. Let me do some research\nover the formats and the background formats in which tools like\nOpenOffice store the data in xml files. May be for docbooks by\nOpenOffice, the best thing would be to give the *diff* output in terms\nof lines.\nI would also appreciate to know what you think and would like to see\nthe output in such case.\n\n>\n> Ciao,\n> Dscho\n>\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nElectronics and Communication Engg.\nNSIT,New Delhi, India\n"},{"id":"107702","messageId":"49B7D84B.6080501@dawes.za.net","threadId":"18261","inReplyTo":"ab9fa62a0903110713k2a21cefbj1e7cd3c126aca8f9@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2009-03-11T15:27:07Z","receivedAt":"2009-03-11T15:27:07Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"saurabh gupta wrote:\n>>> However, I think in merging and notifying about the conflicts in the xml\n>>> files, other things can also be put forward. Like the GUI will show the\n>>> number of tags differing and what are the new tags added and even if any\n>>> tag is renamed with the content unchanged. If possible, how about\n>>> showing a tree like structure (just like DOM model) to compare (or diff)\n>>> the two xml files.\n>>\n>> This is a little bit too low-level for my liking.  Taking the OpenOffice\n>> example again, the GUI should not expose XML at all...\n> \n> hmmmm.....I think I get your point somewhat. Let me do some research\n> over the formats and the background formats in which tools like\n> OpenOffice store the data in xml files. May be for docbooks by\n> OpenOffice, the best thing would be to give the *diff* output in terms\n> of lines.\n> I would also appreciate to know what you think and would like to see\n> the output in such case.\n\nI think that the implementation may make use of features inherent in the\nfile format where possible. e.g. I suspect that OpenOffice has the\nability to show \"Tracked changes\", and then allow the user to view the\nchanges using the actual OpenOffice implementation.\n\nI suspect that that will get a lot more difficult with e.g. conflicts\nand merges, because I doubt that OOo has the ability to show changes\nfrom multiple versions.\n\nBut I have to agree with Dscho, that the output would have to depend on\nthe file type (OOo document), not just the data structure (e.g. XML)\ninside the file.\n\nA regular XML file diff could choose to ignore/collapse whitespace\n(pretty printing) when doing the comparison, to show things like moving\na branch further down the tree.\n\ne.g.\n\n<i>text</i>\n\nvs\n\n<b><i>text</i></b>\n\nvs\n\n<b>\n  <i>text</i>\n</b>\n\nFor plain XML, a textual diff might choose to show it with each element\nun-indented, and a standard text diff output:\n\n+ <b>\n  <i>\n  text\n  </i>\n+ </b>\n\nwhile a GUI diff might show the new element highlighted in a tree:\n\n#green#<b>#/green#\n  <i>\n   text\n\nI think that where reasonable that you should aim to have a text-only\nversion that could be wrapped by a GUI. Obviously, this would be\nmeaningless when diffing a JPG, for instance.\n\nOk, that was a bit rambling. I hope it helped more than it confused.\n\nRogan\n"},{"id":"107703","messageId":"alpine.DEB.1.00.0903111631310.10498@intel-tinevez-2-302","threadId":"18261","inReplyTo":"ab9fa62a0903110713k2a21cefbj1e7cd3c126aca8f9@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T15:38:04Z","receivedAt":"2009-03-11T15:38:04Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, saurabh gupta wrote:\n\n> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n>\n> > On Wed, 11 Mar 2009, saurabh gupta wrote:\n> >\n> >> What I think is to implement file formats other than text like that \n> >> written on wiki i.e. latex, xml, or even any database file (db file). \n> >> Another idea (although it can be weired also) is to implement the new \n> >> file formats in the plug-in formats. For example, to incorporate the \n> >> merger engine for a new file format, a plug-in is created and can be \n> >> integrated with the present merger in the git. However, I am not sure \n> >> how much valid is this idea to make the present merger in git to be \n> >> compatible with the plug-ins for enabling newer file formats.\n> >\n> > I am not sure that a plugin structure is needed.  Take, for example, \n> > three different .xml based formats: OpenOffice documents, .svg files \n> > and Ant build.xml files.  They need very different user interfaces.\n> \n> okay. In that case, if they have a different user interfaces then \n> separate plug-in would be needed for each of these. May be this will get \n> more messy.\n\nThe thing is: \"plugin\" is an architecture issue, which I think we will \nhave plenty of time hashing out.  \"GUI\" is the bigger problem, because if \nwe cannot come up with something that is worth implementing, we can stop \nthe project early.\n\n> >> However, I think in merging and notifying about the conflicts in the \n> >> xml files, other things can also be put forward. Like the GUI will \n> >> show the number of tags differing and what are the new tags added and \n> >> even if any tag is renamed with the content unchanged. If possible, \n> >> how about showing a tree like structure (just like DOM model) to \n> >> compare (or diff) the two xml files.\n> >\n> > This is a little bit too low-level for my liking.  Taking the \n> > OpenOffice example again, the GUI should not expose XML at all...\n> \n> hmmmm.....I think I get your point somewhat. Let me do some research \n> over the formats and the background formats in which tools like \n> OpenOffice store the data in xml files. May be for docbooks by \n> OpenOffice, the best thing would be to give the *diff* output in terms \n> of lines.\n\nActually, I think that the diff is not the issue.  What is needed is a way \nthat is both intuitive and versatile enough that all kinds of merge \nconflicts in OpenOffice documents can be resolved by a total computer \nilliterate.\n\nThe same problem applies for SVG files, but the user interface would look \ncompletely different.\n\nAs such, it might not be wise to have a common framework at all, but to \nmake the first an extension for OpenOffice, and the second a modification \nof, say, inkscape.\n\nOf course, David will then come and say: \"But that is more appropriate a \nproject for OpenOffice and inkscape, then!\".\n\nThe good thing is that this is Open Source, and we'll just ask them to \nco-mentor this project.\n\n> I would also appreciate to know what you think and would like to see the \n> output in such case.\n\nThat's the thing: I do not know yet how it should look like.\n\nCiao,\nDscho\n"},{"id":"107709","messageId":"ab9fa62a0903110921k43599ba5u5187615b28650d89@mail.gmail.com","threadId":"18261","inReplyTo":"49B7D84B.6080501@dawes.za.net","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T16:21:24Z","receivedAt":"2009-03-11T16:21:24Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 8:57 PM, Rogan Dawes <lists@dawes.za.net> wrote:\n> saurabh gupta wrote:\n>>>> However, I think in merging and notifying about the conflicts in the xml\n>>>> files, other things can also be put forward. Like the GUI will show the\n>>>> number of tags differing and what are the new tags added and even if any\n>>>> tag is renamed with the content unchanged. If possible, how about\n>>>> showing a tree like structure (just like DOM model) to compare (or diff)\n>>>> the two xml files.\n>>>\n>>> This is a little bit too low-level for my liking.  Taking the OpenOffice\n>>> example again, the GUI should not expose XML at all...\n>>\n>> hmmmm.....I think I get your point somewhat. Let me do some research\n>> over the formats and the background formats in which tools like\n>> OpenOffice store the data in xml files. May be for docbooks by\n>> OpenOffice, the best thing would be to give the *diff* output in terms\n>> of lines.\n>> I would also appreciate to know what you think and would like to see\n>> the output in such case.\n>\n> I think that the implementation may make use of features inherent in the\n> file format where possible. e.g. I suspect that OpenOffice has the\n> ability to show \"Tracked changes\", and then allow the user to view the\n> changes using the actual OpenOffice implementation.\n>\n> I suspect that that will get a lot more difficult with e.g. conflicts\n> and merges, because I doubt that OOo has the ability to show changes\n> from multiple versions.\n>\n> But I have to agree with Dscho, that the output would have to depend on\n> the file type (OOo document), not just the data structure (e.g. XML)\n> inside the file.\n>\n> A regular XML file diff could choose to ignore/collapse whitespace\n> (pretty printing) when doing the comparison, to show things like moving\n> a branch further down the tree.\n>\n> e.g.\n>\n> <i>text</i>\n>\n> vs\n>\n> <b><i>text</i></b>\n>\n> vs\n>\n> <b>\n>  <i>text</i>\n> </b>\n>\n> For plain XML, a textual diff might choose to show it with each element\n> un-indented, and a standard text diff output:\n>\n> + <b>\n>  <i>\n>  text\n>  </i>\n> + </b>\n>\n> while a GUI diff might show the new element highlighted in a tree:\n>\n> #green#<b>#/green#\n>  <i>\n>   text\n>\n> I think that where reasonable that you should aim to have a text-only\n> version that could be wrapped by a GUI. Obviously, this would be\n> meaningless when diffing a JPG, for instance.\n\nAll right. I got what you mean to say.\n>\n> Ok, that was a bit rambling. I hope it helped more than it confused.\n>\n> Rogan\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nElectronics and Communication Engg.\nNSIT,New Delhi, India\n"},{"id":"107711","messageId":"ab9fa62a0903110929t63fcd40jbf88b21f4a1f37ba@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111631310.10498@intel-tinevez-2-302","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T16:29:19Z","receivedAt":"2009-03-11T16:29:19Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 9:08 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>\n>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin\n>> <Johannes.Schindelin@gmx.de> wrote:\n>>\n>> > On Wed, 11 Mar 2009, saurabh gupta wrote:\n>> >\n>> >> What I think is to implement file formats other than text like that\n>> >> written on wiki i.e. latex, xml, or even any database file (db file).\n>> >> Another idea (although it can be weired also) is to implement the new\n>> >> file formats in the plug-in formats. For example, to incorporate the\n>> >> merger engine for a new file format, a plug-in is created and can be\n>> >> integrated with the present merger in the git. However, I am not sure\n>> >> how much valid is this idea to make the present merger in git to be\n>> >> compatible with the plug-ins for enabling newer file formats.\n>> >\n>> > I am not sure that a plugin structure is needed.  Take, for example,\n>> > three different .xml based formats: OpenOffice documents, .svg files\n>> > and Ant build.xml files.  They need very different user interfaces.\n>>\n>> okay. In that case, if they have a different user interfaces then\n>> separate plug-in would be needed for each of these. May be this will get\n>> more messy.\n>\n> The thing is: \"plugin\" is an architecture issue, which I think we will\n> have plenty of time hashing out.  \"GUI\" is the bigger problem, because if\n> we cannot come up with something that is worth implementing, we can stop\n> the project early.\n\nWe can decide for the GUI part. RIght now, I am going through the\nbackground for Tcl/Tk. I am sure that using this tool will serve the\npurpose in the better way and portability issue can also be kept in\nmind.\n\n\n>> >> However, I think in merging and notifying about the conflicts in the\n>> >> xml files, other things can also be put forward. Like the GUI will\n>> >> show the number of tags differing and what are the new tags added and\n>> >> even if any tag is renamed with the content unchanged. If possible,\n>> >> how about showing a tree like structure (just like DOM model) to\n>> >> compare (or diff) the two xml files.\n>> >\n>> > This is a little bit too low-level for my liking.  Taking the\n>> > OpenOffice example again, the GUI should not expose XML at all...\n>>\n>> hmmmm.....I think I get your point somewhat. Let me do some research\n>> over the formats and the background formats in which tools like\n>> OpenOffice store the data in xml files. May be for docbooks by\n>> OpenOffice, the best thing would be to give the *diff* output in terms\n>> of lines.\n>\n> Actually, I think that the diff is not the issue.  What is needed is a way\n> that is both intuitive and versatile enough that all kinds of merge\n> conflicts in OpenOffice documents can be resolved by a total computer\n> illiterate.\n>\n> The same problem applies for SVG files, but the user interface would look\n> completely different.\n>\n> As such, it might not be wise to have a common framework at all, but to\n> make the first an extension for OpenOffice, and the second a modification\n> of, say, inkscape.\n>\n> Of course, David will then come and say: \"But that is more appropriate a\n> project for OpenOffice and inkscape, then!\".\n>\n> The good thing is that this is Open Source, and we'll just ask them to\n> co-mentor this project.\n\nAll right. I agree with this and We can come up with a plan to\nimplement the thing in an organized way. I agree with you that one\ncommon platform for these will not work because of the way they are\nrepresented and is comfortable for a normal computer user.\n\n>> I would also appreciate to know what you think and would like to see the\n>> output in such case.\n>\n> That's the thing: I do not know yet how it should look like.\n>\n> Ciao,\n> Dscho\n>\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107712","messageId":"alpine.LNX.1.00.0903111159530.19665@iabervon.org","threadId":"18261","inReplyTo":"ab9fa62a0903110713k2a21cefbj1e7cd3c126aca8f9@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-03-11T16:29:38Z","receivedAt":"2009-03-11T16:29:38Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 11 Mar 2009, saurabh gupta wrote:\n\n> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n> > Hi,\n> >\n> > On Wed, 11 Mar 2009, saurabh gupta wrote:\n> >\n> >> What I think is to implement file formats other than text like that\n> >> written on wiki i.e. latex, xml, or even any database file (db file).\n> >> Another idea (although it can be weired also) is to implement the new\n> >> file formats in the plug-in formats. For example, to incorporate the\n> >> merger engine for a new file format, a plug-in is created and can be\n> >> integrated with the present merger in the git. However, I am not sure\n> >> how much valid is this idea to make the present merger in git to be\n> >> compatible with the plug-ins for enabling newer file formats.\n> >\n> > I am not sure that a plugin structure is needed.  Take, for example, three\n> > different .xml based formats: OpenOffice documents, .svg files and Ant\n> > build.xml files.  They need very different user interfaces.\n> \n> okay. In that case, if they have  a different user interfaces then\n> separate plug-in would be needed for each of these. May be this will\n> get more messy.\n\nOne thing that I think would be good whenever possible is to have the \nmerge program generate a file in the same format which is easily \nrecognizable as having conflict markers. For example, I think it should be \npossible to show conflicts in the text of office documents by having \nstyles for each side of the merge, and show each side's content in the \nappropriate style. Then the user opens the document with their choice of \noffice software, finds the things in the conflict styles, and decides what \nthe result should be.\n\nOf course, if the two sides conflict over something that isn't text, it \ngets harder.\n\nAlso remember that, for a merge, there are two important cases: (1) the \ntwo sides changed things that aren't related at all; (2) the two sides \nchanged things that might affect each other. In case (1), the tool should \ntake care of everything automatically and report that it took care of it; \nin case (2), it should reliably determine that user assistance is \nrequired.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"107713","messageId":"alpine.DEB.1.10.0903110931070.13653@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111458340.10498@intel-tinevez-2-302","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-11T16:32:05Z","receivedAt":"2009-03-11T16:32:05Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>\n>> What I think is to implement file formats other than text like that\n>> written on wiki i.e. latex, xml, or even any database file (db file).\n>> Another idea (although it can be weired also) is to implement the new\n>> file formats in the plug-in formats. For example, to incorporate the\n>> merger engine for a new file format, a plug-in is created and can be\n>> integrated with the present merger in the git. However, I am not sure\n>> how much valid is this idea to make the present merger in git to be\n>> compatible with the plug-ins for enabling newer file formats.\n>\n> I am not sure that a plugin structure is needed.  Take, for example, three\n> different .xml based formats: OpenOffice documents, .svg files and Ant\n> build.xml files.  They need very different user interfaces.\n>\n>> I am thinking of using gtk+ libraries to implement the GUI part (I am\n>> quite comfortable with gtk+).\n>\n> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based\n> stuff ;-)\n>\n>> However, I think in merging and notifying about the conflicts in the xml\n>> files, other things can also be put forward. Like the GUI will show the\n>> number of tags differing and what are the new tags added and even if any\n>> tag is renamed with the content unchanged. If possible, how about\n>> showing a tree like structure (just like DOM model) to compare (or diff)\n>> the two xml files.\n>\n> This is a little bit too low-level for my liking.  Taking the OpenOffice\n> example again, the GUI should not expose XML at all...\n\ndon't assume that you have a GUI just to handle a filetype. if you have \none, good, make use of it. but have a fallback for how to deal with things \nif all you have is a text terminal.\n\nDavid Lang\n"},{"id":"107716","messageId":"alpine.DEB.1.00.0903111742360.10498@intel-tinevez-2-302","threadId":"18261","inReplyTo":"alpine.LNX.1.00.0903111159530.19665@iabervon.org","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T16:44:48Z","receivedAt":"2009-03-11T16:44:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, Daniel Barkalow wrote:\n\n> One thing that I think would be good whenever possible is to have the \n> merge program generate a file in the same format which is easily \n> recognizable as having conflict markers. For example, I think it should \n> be possible to show conflicts in the text of office documents by having \n> styles for each side of the merge, and show each side's content in the \n> appropriate style. Then the user opens the document with their choice of \n> office software, finds the things in the conflict styles, and decides \n> what the result should be.\n\nThat's a very good idea!  (Except for LaTeX, maybe...)\n\nFor SVG, you could add both versions of a modified object, for \nexample, maybe with some visual effect to show the version...\n\nCiao,\nDscho\n"},{"id":"107717","messageId":"ab9fa62a0903110958s215a84e6y16b4527ab76cb25b@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.LNX.1.00.0903111159530.19665@iabervon.org","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T16:58:52Z","receivedAt":"2009-03-11T16:58:52Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 9:59 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:\n> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>\n>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin\n>> <Johannes.Schindelin@gmx.de> wrote:\n>> > Hi,\n>> >\n>> > On Wed, 11 Mar 2009, saurabh gupta wrote:\n>> >\n>> >> What I think is to implement file formats other than text like that\n>> >> written on wiki i.e. latex, xml, or even any database file (db file).\n>> >> Another idea (although it can be weired also) is to implement the new\n>> >> file formats in the plug-in formats. For example, to incorporate the\n>> >> merger engine for a new file format, a plug-in is created and can be\n>> >> integrated with the present merger in the git. However, I am not sure\n>> >> how much valid is this idea to make the present merger in git to be\n>> >> compatible with the plug-ins for enabling newer file formats.\n>> >\n>> > I am not sure that a plugin structure is needed.  Take, for example, three\n>> > different .xml based formats: OpenOffice documents, .svg files and Ant\n>> > build.xml files.  They need very different user interfaces.\n>>\n>> okay. In that case, if they have  a different user interfaces then\n>> separate plug-in would be needed for each of these. May be this will\n>> get more messy.\n>\n> One thing that I think would be good whenever possible is to have the\n> merge program generate a file in the same format which is easily\n> recognizable as having conflict markers. For example, I think it should be\n> possible to show conflicts in the text of office documents by having\n> styles for each side of the merge, and show each side's content in the\n> appropriate style. Then the user opens the document with their choice of\n> office software, finds the things in the conflict styles, and decides what\n> the result should be.\n\nWell, I think this is what which is done in case of normal text files\nalso. The conflicts put the markers in the file to indicate the\nchanges and the modification part. However, in the case of OO\ndocuments, we have to change the content for the xml file and when it\nis opened in the office software, the user will get the modified\ncontents.\n\n\n> Of course, if the two sides conflict over something that isn't text, it\n> gets harder.\n>\n> Also remember that, for a merge, there are two important cases: (1) the\n> two sides changed things that aren't related at all; (2) the two sides\n> changed things that might affect each other. In case (1), the tool should\n> take care of everything automatically and report that it took care of it;\n> in case (2), it should reliably determine that user assistance is\n> required.\n>\n>        -Daniel\n> *This .sig left intentionally blank*\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nElectronics and Communication Engg.\nNSIT,New Delhi, India\n"},{"id":"107719","messageId":"alpine.DEB.1.00.0903111800500.10498@intel-tinevez-2-302","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903110931070.13653@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T17:01:29Z","receivedAt":"2009-03-11T17:01:29Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, david@lang.hm wrote:\n\n> On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n> \n> > On Wed, 11 Mar 2009, saurabh gupta wrote:\n> >\n> > > What I think is to implement file formats other than text like that\n> > > written on wiki i.e. latex, xml, or even any database file (db file).\n> > > Another idea (although it can be weired also) is to implement the new\n> > > file formats in the plug-in formats. For example, to incorporate the\n> > > merger engine for a new file format, a plug-in is created and can be\n> > > integrated with the present merger in the git. However, I am not sure\n> > > how much valid is this idea to make the present merger in git to be\n> > > compatible with the plug-ins for enabling newer file formats.\n> >\n> > I am not sure that a plugin structure is needed.  Take, for example, three\n> > different .xml based formats: OpenOffice documents, .svg files and Ant\n> > build.xml files.  They need very different user interfaces.\n> >\n> > > I am thinking of using gtk+ libraries to implement the GUI part (I am\n> > > quite comfortable with gtk+).\n> >\n> > I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based\n> > stuff ;-)\n> >\n> > > However, I think in merging and notifying about the conflicts in the xml\n> > > files, other things can also be put forward. Like the GUI will show the\n> > > number of tags differing and what are the new tags added and even if any\n> > > tag is renamed with the content unchanged. If possible, how about\n> > > showing a tree like structure (just like DOM model) to compare (or diff)\n> > > the two xml files.\n> >\n> > This is a little bit too low-level for my liking.  Taking the OpenOffice\n> > example again, the GUI should not expose XML at all...\n> \n> don't assume that you have a GUI just to handle a filetype. if you have one,\n> good, make use of it. but have a fallback for how to deal with things if all\n> you have is a text terminal.\n\nI do not think it makes sense to assume all you have at your hands is a \nterminal when you try to resolve a merge conflict in an .svg file.\n\nCiao,\nDscho\n"},{"id":"107720","messageId":"ab9fa62a0903111007w4772b234x8e6fd19cdc7fc595@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903110931070.13653@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T17:07:13Z","receivedAt":"2009-03-11T17:07:13Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Wed, Mar 11, 2009 at 10:02 PM,  <david@lang.hm> wrote:\n> On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n>\n>> Hi,\n>>\n>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>\n>>> What I think is to implement file formats other than text like that\n>>> written on wiki i.e. latex, xml, or even any database file (db file).\n>>> Another idea (although it can be weired also) is to implement the new\n>>> file formats in the plug-in formats. For example, to incorporate the\n>>> merger engine for a new file format, a plug-in is created and can be\n>>> integrated with the present merger in the git. However, I am not sure\n>>> how much valid is this idea to make the present merger in git to be\n>>> compatible with the plug-ins for enabling newer file formats.\n>>\n>> I am not sure that a plugin structure is needed.  Take, for example, three\n>> different .xml based formats: OpenOffice documents, .svg files and Ant\n>> build.xml files.  They need very different user interfaces.\n>>\n>>> I am thinking of using gtk+ libraries to implement the GUI part (I am\n>>> quite comfortable with gtk+).\n>>\n>> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based\n>> stuff ;-)\n>>\n>>> However, I think in merging and notifying about the conflicts in the xml\n>>> files, other things can also be put forward. Like the GUI will show the\n>>> number of tags differing and what are the new tags added and even if any\n>>> tag is renamed with the content unchanged. If possible, how about\n>>> showing a tree like structure (just like DOM model) to compare (or diff)\n>>> the two xml files.\n>>\n>> This is a little bit too low-level for my liking.  Taking the OpenOffice\n>> example again, the GUI should not expose XML at all...\n>\n> don't assume that you have a GUI just to handle a filetype. if you have one,\n> good, make use of it. but have a fallback for how to deal with things if all\n> you have is a text terminal.\n\nIn case of only a terminal, It would be very difficult to show an OO\ndocument to represent the *diff* output in both text as well in GUI.\nFor example, to indicate the changes in an OO document, we will have\nto change the underlying XML file appropriately to show the markers\nsigns and other things in the conflict file. Now, if this file is\nopened in terminal, it would not be at all comprehensible to see the\ndifferences.\n\nThe main thing is that to create *diff* for different file formats, we\nwill have to write the parser code accordingly.\n\n> David Lang\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107724","messageId":"alpine.DEB.1.10.0903111223470.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903111007w4772b234x8e6fd19cdc7fc595@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-11T19:29:29Z","receivedAt":"2009-03-11T19:29:29Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 11 Mar 2009, saurabh gupta wrote:\n\n> On Wed, Mar 11, 2009 at 10:02 PM,  <david@lang.hm> wrote:\n>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n>>\n>>> Hi,\n>>>\n>>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>>\n>>>> What I think is to implement file formats other than text like that\n>>>> written on wiki i.e. latex, xml, or even any database file (db file).\n>>>> Another idea (although it can be weired also) is to implement the new\n>>>> file formats in the plug-in formats. For example, to incorporate the\n>>>> merger engine for a new file format, a plug-in is created and can be\n>>>> integrated with the present merger in the git. However, I am not sure\n>>>> how much valid is this idea to make the present merger in git to be\n>>>> compatible with the plug-ins for enabling newer file formats.\n>>>\n>>> I am not sure that a plugin structure is needed.  Take, for example, three\n>>> different .xml based formats: OpenOffice documents, .svg files and Ant\n>>> build.xml files.  They need very different user interfaces.\n>>>\n>>>> I am thinking of using gtk+ libraries to implement the GUI part (I am\n>>>> quite comfortable with gtk+).\n>>>\n>>> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based\n>>> stuff ;-)\n>>>\n>>>> However, I think in merging and notifying about the conflicts in the xml\n>>>> files, other things can also be put forward. Like the GUI will show the\n>>>> number of tags differing and what are the new tags added and even if any\n>>>> tag is renamed with the content unchanged. If possible, how about\n>>>> showing a tree like structure (just like DOM model) to compare (or diff)\n>>>> the two xml files.\n>>>\n>>> This is a little bit too low-level for my liking.  Taking the OpenOffice\n>>> example again, the GUI should not expose XML at all...\n>>\n>> don't assume that you have a GUI just to handle a filetype. if you have one,\n>> good, make use of it. but have a fallback for how to deal with things if all\n>> you have is a text terminal.\n>\n> In case of only a terminal, It would be very difficult to show an OO\n> document to represent the *diff* output in both text as well in GUI.\n> For example, to indicate the changes in an OO document, we will have\n> to change the underlying XML file appropriately to show the markers\n> signs and other things in the conflict file. Now, if this file is\n> opened in terminal, it would not be at all comprehensible to see the\n> differences.\n>\n> The main thing is that to create *diff* for different file formats, we\n> will have to write the parser code accordingly.\n\ncorrect, and in the case of an XML file, the meaningful diff can be \nsubstantially shorter than what a text diff of the two files would be \n(whitespace changes that don't matter, even some tag ordering changes \nmay not matter)\n\nI'm just asking that you don't get so fixated on what can be done in a GUI \nthat you provide no benifit to people who don't have the GUI\n\nthere are a _lot_ of XML based formats out there, having a diff/merge \ncapability to make dealing with them better than just treating them as \ntext files would be a _very_ useful thing.\n\ngoing beyond that and creating the ability to do the markup in \napplication-specific ways, and present it to the user in a nice GUI would \nalso be nice, but these are a step up after having the basic XML handling \nthat isn't specific to a particular application.\n\nDavid Lang\n"},{"id":"107725","messageId":"alpine.DEB.1.10.0903111229330.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111800500.10498@intel-tinevez-2-302","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-11T19:30:37Z","receivedAt":"2009-03-11T19:30:37Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 11 Mar 2009, david@lang.hm wrote:\n>\n>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n>>\n>>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>>\n>>>> What I think is to implement file formats other than text like that\n>>>> written on wiki i.e. latex, xml, or even any database file (db file).\n>>>> Another idea (although it can be weired also) is to implement the new\n>>>> file formats in the plug-in formats. For example, to incorporate the\n>>>> merger engine for a new file format, a plug-in is created and can be\n>>>> integrated with the present merger in the git. However, I am not sure\n>>>> how much valid is this idea to make the present merger in git to be\n>>>> compatible with the plug-ins for enabling newer file formats.\n>>>\n>>> I am not sure that a plugin structure is needed.  Take, for example, three\n>>> different .xml based formats: OpenOffice documents, .svg files and Ant\n>>> build.xml files.  They need very different user interfaces.\n>>>\n>>>> I am thinking of using gtk+ libraries to implement the GUI part (I am\n>>>> quite comfortable with gtk+).\n>>>\n>>> I mentioned Tcl/Tk, because it is portable, but I'll also take gtk-based\n>>> stuff ;-)\n>>>\n>>>> However, I think in merging and notifying about the conflicts in the xml\n>>>> files, other things can also be put forward. Like the GUI will show the\n>>>> number of tags differing and what are the new tags added and even if any\n>>>> tag is renamed with the content unchanged. If possible, how about\n>>>> showing a tree like structure (just like DOM model) to compare (or diff)\n>>>> the two xml files.\n>>>\n>>> This is a little bit too low-level for my liking.  Taking the OpenOffice\n>>> example again, the GUI should not expose XML at all...\n>>\n>> don't assume that you have a GUI just to handle a filetype. if you have one,\n>> good, make use of it. but have a fallback for how to deal with things if all\n>> you have is a text terminal.\n>\n> I do not think it makes sense to assume all you have at your hands is a\n> terminal when you try to resolve a merge conflict in an .svg file.\n\nI'm not saying that you assume that all you have is a terminal, I'm saying \nthat you _support_ the case that all you have is a terminal.\n\nDavid Lang\n"},{"id":"107727","messageId":"7vtz5z4zsx.fsf@gitster.siamese.dyndns.org","threadId":"18261","inReplyTo":"49B74373.3090609@gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-11T19:36:30Z","receivedAt":"2009-03-11T19:36:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Saurabh Gupta <saurabhgupta1403@gmail.com> writes:\n\n> *1) Domain specific merge helpers*\n> Intelligence in the merger can be put which modifies the source file\n> according the format. Different file formats can be put in the merger\n> to support.\n\nThe way \"merge\" works is:\n\n - A tree-level 3-way merge is done (either inside merge-recursive backend\n   or with \"read-tree -m O A B\" inside merge-resolve), and trivial merges\n   are resolved at the whole-file level without need for any helper.\n   Roughly speaking, the definition of \"a trivially mergeable path\" is a\n   path that only one side modified while the other side didn't, or both\n   sides modified identically.\n\n - The remaining paths need to be merged at file level.  The gitattributes\n   mechanism is used to decide what exact algorithm to use based on what\n   the merged file is; we have a plain-text \"xdl\" merge driver and \"union\"\n   merge driver built-in, in addition to \"binary\" merge driver (which\n   always says \"the changes conflict; use ours as a tentative result).\n\n   When a merge driver is called, it is given three blobs: original, ours\n   and theirs (any one of them could be missing).  It is the driver's\n   responsibility to come up with an automated merge result when the\n   changes do not overlap and report success, or leave an intermediate\n   \"conflicted merge\" and report conflicts.  In either case, the driver is\n   expected to return _one_ single bytestream as its tentative result.\n\n - Cleanly merged paths are updated in the index and their results are\n   written out to the work tree.  For paths the merge drivers reported\n   conflicts, tentative results returned by the merge drivers are written\n   out to the work tree but the index entries for them are left in an\n   unmerged state.\n\n - If all paths are cleanly merged, \"git merge\" and friends write the\n   index out as a tree and create a commit out of it (unless otherwise\n   instructed) and report success.\n\n - When a merge left conflicts, the user can use external tools like \"git\n   mergetool\" to resolve the conflict in the work tree, starting from the\n   tentative result given by the merge driver, and \"git add\" to register\n   the resolution to the index.\n\nWhen people say a \"merge helper\" in the context of git, I think they think\nabout at least two kinds, that work at very different layers.  It is\nunclear which one you are more interested in, or you are tackling both.\n\n - A group of new merge drivers that handle various structured text\n   formats (e.g. XML based ones), on which the default plain-text merge is\n   not suitable, would be a good addition to the git suite.  If you are\n   interested in doing this as your GSoC project, it would very much be\n   git specific.\n\n - Amerge helper that takes three files (original, ours and theirs) as its\n   input and helps the end user (perhaps graphically) merge them can be\n   used at a backend to the \"git-mergetool\", by registering a filetype as\n   \"binary\" (so that the low-level merge driver won't even try merging the\n   contents at the file level), and letting \"git-mergetool\" invoke the\n   \"helper\" with these three files.  The development of this kind of\n   \"helper\" would not be a git specific project.\n\nObviously it would help the users to have both, but which kind is more\nimportant?\n\nIn a collaborative environment, people do not work in void without any\ncommunication with each other, and they actively try not to step on each\nother's toes.  Even when changes are made from both sides of a merge to\nthe same file (in other words, a file level merge is required), in the\nmajority of cases, the changes do not overlap, and being able to resolve\nsuch merges cleanly most of the time, without having to resort to an\nexternal \"git mergetool\", is a huge win in productivity.  I think a domain\nspecific \"merge driver\" project would benefit the git users a lot more\nthan a domain specific \"merge helper\" that can be used as a \"git\nmergetool\" backend (and can also be used outside git).\n\nOf course, you can do both.\n\nBut my point is it is unclear which one you meant when you said \"merge\nhelper\".\n"},{"id":"107729","messageId":"alpine.DEB.1.00.0903112049470.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903111229330.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T19:55:22Z","receivedAt":"2009-03-11T19:55:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, david@lang.hm wrote:\n\n> On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n> \n> > On Wed, 11 Mar 2009, david@lang.hm wrote:\n> >\n> > > On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n> > >\n> > > > On Wed, 11 Mar 2009, saurabh gupta wrote:\n> > > >\n> > > > > What I think is to implement file formats other than text like \n> > > > > that written on wiki i.e. latex, xml, or even any database file \n> > > > > (db file). Another idea (although it can be weired also) is to \n> > > > > implement the new file formats in the plug-in formats. For \n> > > > > example, to incorporate the merger engine for a new file format, \n> > > > > a plug-in is created and can be integrated with the present \n> > > > > merger in the git. However, I am not sure how much valid is this \n> > > > > idea to make the present merger in git to be compatible with the \n> > > > > plug-ins for enabling newer file formats.\n> > > >\n> > > > I am not sure that a plugin structure is needed.  Take, for \n> > > > example, three different .xml based formats: OpenOffice documents, \n> > > > .svg files and Ant build.xml files.  They need very different user \n> > > > interfaces.\n> > > >\n> > > > > I am thinking of using gtk+ libraries to implement the GUI part \n> > > > > (I am quite comfortable with gtk+).\n> > > >\n> > > > I mentioned Tcl/Tk, because it is portable, but I'll also take \n> > > > gtk-based stuff ;-)\n> > > >\n> > > > > However, I think in merging and notifying about the conflicts in \n> > > > > the xml files, other things can also be put forward. Like the \n> > > > > GUI will show the number of tags differing and what are the new \n> > > > > tags added and even if any tag is renamed with the content \n> > > > > unchanged. If possible, how about showing a tree like structure \n> > > > > (just like DOM model) to compare (or diff) the two xml files.\n> > > >\n> > > > This is a little bit too low-level for my liking.  Taking the \n> > > > OpenOffice example again, the GUI should not expose XML at all...\n> > >\n> > > don't assume that you have a GUI just to handle a filetype. if you \n> > > have one, good, make use of it. but have a fallback for how to deal \n> > > with things if all you have is a text terminal.\n> >\n> > I do not think it makes sense to assume all you have at your hands is \n> > a terminal when you try to resolve a merge conflict in an .svg file.\n> \n> I'm not saying that you assume that all you have is a terminal, I'm \n> saying that you _support_ the case that all you have is a terminal.\n\nSorry, no, the GSoC idea was not about \"merge helpers that run also in a \nterminal\".  The idea was about \"Domain specific merge helpers\".\n\nIf I can choose, I'd rather have support for one more merge helper, even \nif it is all graphical, than an enhancement to support also a terminal.\n\nWhile I am dreaming: this is the list of domains _I_ would like to see \nsupported: LaTeX, OpenOffice documents, .svg files.\n\nBut that is not up to me to decide, just to suggest.\n\nCiao,\nDscho\n"},{"id":"107730","messageId":"ab9fa62a0903111302j46c46c2q96af497fa2ac513e@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903111223470.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-11T20:02:02Z","receivedAt":"2009-03-11T20:02:02Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Thu, Mar 12, 2009 at 12:59 AM,  <david@lang.hm> wrote:\n> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>\n>> On Wed, Mar 11, 2009 at 10:02 PM,  <david@lang.hm> wrote:\n>>>\n>>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n>>>\n>>>> Hi,\n>>>>\n>>>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>>>\n>>\n>> In case of only a terminal, It would be very difficult to show an OO\n>> document to represent the *diff* output in both text as well in GUI.\n>> For example, to indicate the changes in an OO document, we will have\n>> to change the underlying XML file appropriately to show the markers\n>> signs and other things in the conflict file. Now, if this file is\n>> opened in terminal, it would not be at all comprehensible to see the\n>> differences.\n>>\n>> The main thing is that to create *diff* for different file formats, we\n>> will have to write the parser code accordingly.\n>\n> correct, and in the case of an XML file, the meaningful diff can be\n> substantially shorter than what a text diff of the two files would be\n> (whitespace changes that don't matter, even some tag ordering changes may\n> not matter)\n>\n> I'm just asking that you don't get so fixated on what can be done in a GUI\n> that you provide no benifit to people who don't have the GUI\n>\n> there are a _lot_ of XML based formats out there, having a diff/merge\n> capability to make dealing with them better than just treating them as text\n> files would be a _very_ useful thing.\n>\n> going beyond that and creating the ability to do the markup in\n> application-specific ways, and present it to the user in a nice GUI would\n> also be nice, but these are a step up after having the basic XML handling\n> that isn't specific to a particular application.\n\nYes, but the thing is that the underlying codes and method will be\ndifferent for GUI part and terminal part to make it readable and\nunderstandable. Like for OO Documents, if we aim to show the *diff*\noutput in the Office tool, then we have to change the xml file\naccordingly. But the same xml file when used with terminal only, the\n*diff* output is not clear.\n\nAs Johannes said in above post that for OO documents, while showing\nthe *diff* result, no xml data should be shown.\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107734","messageId":"alpine.DEB.1.10.0903111307050.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903111302j46c46c2q96af497fa2ac513e@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-11T20:21:05Z","receivedAt":"2009-03-11T20:21:05Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 12 Mar 2009, saurabh gupta wrote:\n\n> On Thu, Mar 12, 2009 at 12:59 AM,  <david@lang.hm> wrote:\n>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>\n>>> On Wed, Mar 11, 2009 at 10:02 PM,  <david@lang.hm> wrote:\n>>>>\n>>>> On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n>>>>\n>>>>> Hi,\n>>>>>\n>>>>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>>>>\n>>>\n>>> In case of only a terminal, It would be very difficult to show an OO\n>>> document to represent the *diff* output in both text as well in GUI.\n>>> For example, to indicate the changes in an OO document, we will have\n>>> to change the underlying XML file appropriately to show the markers\n>>> signs and other things in the conflict file. Now, if this file is\n>>> opened in terminal, it would not be at all comprehensible to see the\n>>> differences.\n>>>\n>>> The main thing is that to create *diff* for different file formats, we\n>>> will have to write the parser code accordingly.\n>>\n>> correct, and in the case of an XML file, the meaningful diff can be\n>> substantially shorter than what a text diff of the two files would be\n>> (whitespace changes that don't matter, even some tag ordering changes may\n>> not matter)\n>>\n>> I'm just asking that you don't get so fixated on what can be done in a GUI\n>> that you provide no benifit to people who don't have the GUI\n>>\n>> there are a _lot_ of XML based formats out there, having a diff/merge\n>> capability to make dealing with them better than just treating them as text\n>> files would be a _very_ useful thing.\n>>\n>> going beyond that and creating the ability to do the markup in\n>> application-specific ways, and present it to the user in a nice GUI would\n>> also be nice, but these are a step up after having the basic XML handling\n>> that isn't specific to a particular application.\n>\n> Yes, but the thing is that the underlying codes and method will be\n> different for GUI part and terminal part to make it readable and\n> understandable. Like for OO Documents, if we aim to show the *diff*\n> output in the Office tool, then we have to change the xml file\n> accordingly. But the same xml file when used with terminal only, the\n> *diff* output is not clear.\n>\n> As Johannes said in above post that for OO documents, while showing\n> the *diff* result, no xml data should be shown.\n\nin part we are talking about different aspects of things, and we were all \nwrong.\n\nsee the e-mail a little bit ago by Junio\n\nthere are two types of helpers that can be written\n\n1. a low-level part that does the simple merges automaticaly and leaves \nbehind appropriate conflict markers when it can't\n\nthere is no GUI involved with this.\n\nwhat 'appropriate conflict markers' are can vary from XML file to XML file\n\n\n2. after a conflict has taken place, a helper to work with the user to \nresolve the conflict\n\nthis can have a GUI and/or a text UI and is tied to the 'appropriate \nconflict markers' as defined in #1, and can be _very_ tightly coupled to \nthe specific use of the XML file.\n\nI think it's very important to have a text UI tool that can be used for \nthe conflict resolution step as well as supporting GUI tools.\n\n\nbesides XML-based formats, a couple other formats that I think would be \nuseful to be smarter about\n\nunordered config files\n   files where config options can appear in any order\n\n   optionally: comments are similar to whitespace (they can be ignored)\n\n'paragraph' based config files\n   files where config options are orginized into 'paragraphs' where the \nparagraphs can be re-ordered\n\n   the definition of what's a paragraph may differ, support having \ndifferent defintions\n     examples:\n      the git config file has a high level tag that starts on the left margin with the sub-tags indented\n      the apache config file can have single entries or 'XML like' sections\n\n   optionally: comments are similar to whitespace (they can be ignored)\n\n\nDavid Lang\n"},{"id":"107736","messageId":"alpine.DEB.1.00.0903112136560.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903111307050.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-11T20:37:48Z","receivedAt":"2009-03-11T20:37:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 11 Mar 2009, david@lang.hm wrote:\n\n> there are two types of helpers that can be written\n> \n> 1. a low-level part that does the simple merges automaticaly and leaves \n>    behind appropriate conflict markers when it can't\n> \n> [...]\n> \n> \n> 2. after a conflict has taken place, a helper to work with the user to \n>    resolve the conflict\n\nI thought that from my description on the wiki it was obvious that both \nare needed.\n\nCiao,\nDscho\n"},{"id":"107737","messageId":"alpine.DEB.1.10.0903111401520.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903112136560.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-11T21:05:56Z","receivedAt":"2009-03-11T21:05:56Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Wed, 11 Mar 2009, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Wed, 11 Mar 2009, david@lang.hm wrote:\n>\n>> there are two types of helpers that can be written\n>>\n>> 1. a low-level part that does the simple merges automaticaly and leaves\n>>    behind appropriate conflict markers when it can't\n>>\n>> [...]\n>>\n>>\n>> 2. after a conflict has taken place, a helper to work with the user to\n>>    resolve the conflict\n>\n> I thought that from my description on the wiki it was obvious that both\n> are needed.\n\nfirst off, I'll admit that I am just going by what's been posted here, I \nhaven't gone looking on the wiki.\n\nsecondly, I somewhat disagree with you. #1 is needed for any new formats \nthat are goning to be handled, but #2 may not be.\n\ntake the case of OO documents, you may not need to write a conflict \nresolver helper. the 'appropriate conflict markers' may be something that \nshows up in your normal OO document editor similar to how the ====> shows \nup in a text editor for text conflicts\n\nDavid Lang\n"},{"id":"107740","messageId":"7veix33f5e.fsf@gitster.siamese.dyndns.org","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903111401520.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-11T21:47:57Z","receivedAt":"2009-03-11T21:47:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n>>> there are two types of helpers that can be written\n>>>\n>>> 1. a low-level part that does the simple merges automaticaly and leaves\n>>>    behind appropriate conflict markers when it can't\n>>>\n>>> 2. after a conflict has taken place, a helper to work with the user to\n>>>    resolve the conflict\n> ...\n> secondly, I somewhat disagree with you. #1 is needed for any new\n> formats that are goning to be handled, but #2 may not be.\n>\n> take the case of OO documents, you may not need to write a conflict\n> resolver helper. the 'appropriate conflict markers' may be something\n> that shows up in your normal OO document editor similar to how the\n> ====> shows up in a text editor for text conflicts\n\nYou can cut it both ways.  For an OO document, you do not necessarily need\nany file-level merger at the driver level, but just let the \"binary\"\ndriver declare conflicts and punt.  A merge helper can do all the work\nstarting from the \"original, ours and theirs\" that are not smudged with\nconflict markers.\n\nBetween these two extremes, the discussion from other people in the thread\nseemed to all focus too heavily on the \"driver punts\" approach, forgetting\nthat mergetool is useful only because most of the time we do not have to\neven use it, thanks to the fact that \"xdl\" driver works reasonably well\nfor most trivial cases where branches being merged stayed away from each\nother, which is the majority case.  It is a huge win from the productivity\npoint of view, and many people might be unaware of it because it is so\ninvisible.\n\nHandling trivial cases safely and automatically at the driver level, if\nyou can figure out how, lets the user focus on hard cases that needs\nmanual intervention, and \"merge helper\" is about helping that manual\nintervention step.\n\nBeing aware of these two distinct layers allows you to realize that there\nis a third possibility.  The driver could notice the cases it can resolve\ncleanly and return a cleanly merged result.  When it cannot autoresolve,\nbut there is no way to \"mark\" a tentative result with conflict markers, it\ncan do the same thing as the \"binary\" driver and let the mergetool backend\nhandle the \"driver punted\" case.\n"},{"id":"107758","messageId":"20090312125709.qnfnw7glc4ko8soo@webmail.fussycoder.id.au","threadId":"18261","inReplyTo":"7veix33f5e.fsf@gitster.siamese.dyndns.org","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"thestar@fussycoder.id.au","sentAt":"2009-03-12T01:57:09Z","receivedAt":"2009-03-12T01:57:09Z","isPatch":false,"sender":{"key":"thestar@fussycoder.id.au","avatar":null},"body":"<Entire conversation snipped>\n\nGuys, I'm sure you're only using OpenOffice.org documents as an  \nexample to facilitate discussing merge helpers, but I feel the need to  \npoint out that one can already merge OpenOffice documents using  \nOpenOffice to do so. (And I have done so in the past while reconciling  \ndifferences between some spreadsheets).\n\nHowever, the interface OpenOffice provides for that is awful and very  \nconfusing, but it is there. :)\n\nThe document merge provided by Microsoft Office 2003 is vastly  \nsuperior imho, however it only provides 'change markers' - and doesn't  \nhelp you do the actual merge - one must do a merge to get the change  \nannotations, and then manually modify a new copy with those updates  \nyou feel are neccessary.\n  - This is one feature that does not appear to be present in  \nMicrosoft Office 2007, by the way...\n"},{"id":"107770","messageId":"7vy6vbi3ze.fsf@gitster.siamese.dyndns.org","threadId":"18261","inReplyTo":"20090312125709.qnfnw7glc4ko8soo@webmail.fussycoder.id.au","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-12T07:40:05Z","receivedAt":"2009-03-12T07:40:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"thestar@fussycoder.id.au writes:\n\n> <Entire conversation snipped>\n\nWhich is not appreciated at all.\n\n> Guys, I'm sure you're only using OpenOffice.org documents as an\n> example to facilitate discussing merge helpers, but I feel the need to\n> point out that one can already merge OpenOffice documents using\n> OpenOffice to do so. (And I have done so in the past while reconciling\n> differences between some spreadsheets).\n\nIt sounds like OOo itself can be counted as a \"domain specific merge\nhelper\" in the second sense of the word---it wouldn't work as a merge\ndriver but the end user can use it to merge the forked documents.\n\nWhich is good to know ;-)\n"},{"id":"107818","messageId":"ab9fa62a0903120542s45b1ceebwddab932891c47cf0@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903111307050.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-12T12:42:02Z","receivedAt":"2009-03-12T12:42:02Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"hello,\n\nOn Thu, Mar 12, 2009 at 1:51 AM,  <david@lang.hm> wrote:\n>\n>> Yes, but the thing is that the underlying codes and method will be\n>> different for GUI part and terminal part to make it readable and\n>> understandable. Like for OO Documents, if we aim to show the *diff*\n>> output in the Office tool, then we have to change the xml file\n>> accordingly. But the same xml file when used with terminal only, the\n>> *diff* output is not clear.\n>>\n>> As Johannes said in above post that for OO documents, while showing\n>> the *diff* result, no xml data should be shown.\n>\n> in part we are talking about different aspects of things, and we were all\n> wrong.\n>\n> see the e-mail a little bit ago by Junio\n>\n> there are two types of helpers that can be written\n>\n> 1. a low-level part that does the simple merges automaticaly and leaves\n> behind appropriate conflict markers when it can't\n>\n> there is no GUI involved with this.\n>\n> what 'appropriate conflict markers' are can vary from XML file to XML file\n>\n>\n> 2. after a conflict has taken place, a helper to work with the user to\n> resolve the conflict\n>\n> this can have a GUI and/or a text UI and is tied to the 'appropriate\n> conflict markers' as defined in #1, and can be _very_ tightly coupled to the\n> specific use of the XML file.\n>\n> I think it's very important to have a text UI tool that can be used for the\n> conflict resolution step as well as supporting GUI tools.\n\nAll right. What I can understand from the current situation is that\nfor merging and marking conflicts in xml (for example) files has\nfollowing things to do.\n\nOne, if the markers are put in the xml files like that of a text file,\none can see the difference using a text editor or a terminal. But if\nthe same xml file is to be opened in another editor which expects a\nvalid xml (as clearly mentioned on the wiki ideas for GIT), then a\nmerge helper is needed.\n\nBut if the conflict markers are put in a way to make the xml file\nstill valid which can be then opened in the appropriate editor, then\nthe marking will be different. The merge driver has to produce the\nconflicted merged file in a manner which is still a valid xml file and\nuser has the choice to open it in his own editor to resolve the\nconflicts.\n\n\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107819","messageId":"ab9fa62a0903120545o7e5bc359g7df233b00858869c@mail.gmail.com","threadId":"18261","inReplyTo":"7veix33f5e.fsf@gitster.siamese.dyndns.org","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-12T12:45:02Z","receivedAt":"2009-03-12T12:45:02Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>\n> You can cut it both ways.  For an OO document, you do not necessarily need\n> any file-level merger at the driver level, but just let the \"binary\"\n> driver declare conflicts and punt.  A merge helper can do all the work\n> starting from the \"original, ours and theirs\" that are not smudged with\n> conflict markers.\n>\n> Between these two extremes, the discussion from other people in the thread\n> seemed to all focus too heavily on the \"driver punts\" approach, forgetting\n> that mergetool is useful only because most of the time we do not have to\n> even use it, thanks to the fact that \"xdl\" driver works reasonably well\n> for most trivial cases where branches being merged stayed away from each\n> other, which is the majority case.  It is a huge win from the productivity\n> point of view, and many people might be unaware of it because it is so\n> invisible.\n\nIf I am not wrong, then for merging two xml files, if we use a simple\nxdl merge driver then it will mark the conflicts in the normal way as\nit does for simple text files. As far as I can understand, the\nfollowing things are supposed to be aimed here taking an example of\nxml file:\n\n\n=>Merging of two xml files\n\n=> existing merge driver (like xdl) is called which marks the\nconflicts points just like a normal text file.\n\n=> the conflicted file can be read through a text terminal and\nconflicted lines can be seen.\n\n=> suppose the xml file is from the domain of OO document. Then, a\nmerge helper for OO xml type file is called which takes input as the\nconflicted file produced by xdl driver.\n\n=> The merge helper creates a new file or changes the input file to\nmake it a valid xml file so that it can be opened in OpenOffice and\nuser can see the markers like \"====\" or \"<<<<<\"  in an appropriate\nmanner and can resolve the file manually.\n\n\n> When it cannot autoresolve,\n> but there is no way to \"mark\" a tentative result with conflict markers, it\n> can do the same thing as the \"binary\" driver and let the mergetool backend\n> handle the \"driver punted\" case.\n\nI think you mean to say that in case, there is a conflict and the\nchanges don't overlap, then merge driver leaves the file as it is and\nthe merge helper will handle the file.\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107821","messageId":"49B90460.2020803@drmicha.warpmail.net","threadId":"18261","inReplyTo":"ab9fa62a0903110958s215a84e6y16b4527ab76cb25b@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-12T12:47:28Z","receivedAt":"2009-03-12T12:47:28Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"saurabh gupta venit, vidit, dixit 11.03.2009 17:58:\n> On Wed, Mar 11, 2009 at 9:59 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:\n>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>\n>>> On Wed, Mar 11, 2009 at 7:32 PM, Johannes Schindelin\n>>> <Johannes.Schindelin@gmx.de> wrote:\n>>>> Hi,\n>>>>\n>>>> On Wed, 11 Mar 2009, saurabh gupta wrote:\n>>>>\n>>>>> What I think is to implement file formats other than text like that\n>>>>> written on wiki i.e. latex, xml, or even any database file (db file).\n>>>>> Another idea (although it can be weired also) is to implement the new\n>>>>> file formats in the plug-in formats. For example, to incorporate the\n>>>>> merger engine for a new file format, a plug-in is created and can be\n>>>>> integrated with the present merger in the git. However, I am not sure\n>>>>> how much valid is this idea to make the present merger in git to be\n>>>>> compatible with the plug-ins for enabling newer file formats.\n>>>> I am not sure that a plugin structure is needed.  Take, for example, three\n>>>> different .xml based formats: OpenOffice documents, .svg files and Ant\n>>>> build.xml files.  They need very different user interfaces.\n>>> okay. In that case, if they have  a different user interfaces then\n>>> separate plug-in would be needed for each of these. May be this will\n>>> get more messy.\n>> One thing that I think would be good whenever possible is to have the\n>> merge program generate a file in the same format which is easily\n>> recognizable as having conflict markers. For example, I think it should be\n>> possible to show conflicts in the text of office documents by having\n>> styles for each side of the merge, and show each side's content in the\n>> appropriate style. Then the user opens the document with their choice of\n>> office software, finds the things in the conflict styles, and decides what\n>> the result should be.\n> Well, I think this is what which is done in case of normal text files\n> also. The conflicts put the markers in the file to indicate the\n> changes and the modification part. However, in the case of OO\n> documents, we have to change the content for the xml file and when it\n> is opened in the office software, the user will get the modified\n> contents.\n\nOO already knows versioned documents and recording of changes. It can\neven merge documents which are different modifications of the same base\ndocument (assuming all authors used recording of changes) and compare\npossibly unrelated documents, merging them interactively. At least OO 3\ncan do that. So I guess for OO one mostly has to figure out how to call\nthat stuff from the command line. Heck, even MS Office can do that.\nRemember those docs with recorded changes, where published documents\ncontained the deletions as well as the deleted passages?\n\nMichael\n"},{"id":"107823","messageId":"49B90683.1060501@drmicha.warpmail.net","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903111742360.10498@intel-tinevez-2-302","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-12T12:56:35Z","receivedAt":"2009-03-12T12:56:35Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 11.03.2009 17:44:\n> Hi,\n> \n> On Wed, 11 Mar 2009, Daniel Barkalow wrote:\n> \n>> One thing that I think would be good whenever possible is to have the \n>> merge program generate a file in the same format which is easily \n>> recognizable as having conflict markers. For example, I think it should \n>> be possible to show conflicts in the text of office documents by having \n>> styles for each side of the merge, and show each side's content in the \n>> appropriate style. Then the user opens the document with their choice of \n>> office software, finds the things in the conflict styles, and decides \n>> what the result should be.\n> That's a very good idea!  (Except for LaTeX, maybe...)\n\nlatexdiff (in perl) may give you a head start (or ache, I dunno).\n\n> For SVG, you could add both versions of a modified object, for \n> example, maybe with some visual effect to show the version...\n\nLayers maybe?\n\nI think for most formats, content changes could be handled well, while\nchanges in macro definitions or global settings are somewhat hopeless.\n\nMichael\n"},{"id":"107825","messageId":"alpine.DEB.1.00.0903121407070.6335@intel-tinevez-2-302","threadId":"18261","inReplyTo":"49B90683.1060501@drmicha.warpmail.net","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-12T13:07:48Z","receivedAt":"2009-03-12T13:07:48Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 12 Mar 2009, Michael J Gruber wrote:\n\n> Johannes Schindelin venit, vidit, dixit 11.03.2009 17:44:\n> \n> > On Wed, 11 Mar 2009, Daniel Barkalow wrote:\n> > \n> >> One thing that I think would be good whenever possible is to have the \n> >> merge program generate a file in the same format which is easily \n> >> recognizable as having conflict markers. For example, I think it \n> >> should be possible to show conflicts in the text of office documents \n> >> by having styles for each side of the merge, and show each side's \n> >> content in the appropriate style. Then the user opens the document \n> >> with their choice of office software, finds the things in the \n> >> conflict styles, and decides what the result should be.\n> > That's a very good idea!  (Except for LaTeX, maybe...)\n> \n> latexdiff (in perl) may give you a head start (or ache, I dunno).\n\nNo.  latexdiff is about diffing.  It does nothing to help me resolve a \nconflict.\n\nThanks,\nDscho\n"},{"id":"107827","messageId":"49B90AE4.9030904@drmicha.warpmail.net","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903121407070.6335@intel-tinevez-2-302","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-03-12T13:15:16Z","receivedAt":"2009-03-12T13:15:16Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 12.03.2009 14:07:\n> Hi,\n> \n> On Thu, 12 Mar 2009, Michael J Gruber wrote:\n> \n>> Johannes Schindelin venit, vidit, dixit 11.03.2009 17:44:\n>>\n>>> On Wed, 11 Mar 2009, Daniel Barkalow wrote:\n>>>\n>>>> One thing that I think would be good whenever possible is to have the \n>>>> merge program generate a file in the same format which is easily \n>>>> recognizable as having conflict markers. For example, I think it \n>>>> should be possible to show conflicts in the text of office documents \n>>>> by having styles for each side of the merge, and show each side's \n>>>> content in the appropriate style. Then the user opens the document \n>>>> with their choice of office software, finds the things in the \n>>>> conflict styles, and decides what the result should be.\n>>> That's a very good idea!  (Except for LaTeX, maybe...)\n>> latexdiff (in perl) may give you a head start (or ache, I dunno).\n> No.  latexdiff is about diffing.  It does nothing to help me resolve a \n> conflict.\n\nSure. If you want to merge you have to diff first (and display it). That\nwould be the \"head start\". Then you have to think about the merge.\nThat's where the \"head ache\" kicks in...\n\nMichael\n"},{"id":"107857","messageId":"alpine.DEB.1.10.0903121052310.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903120545o7e5bc359g7df233b00858869c@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-12T18:00:12Z","receivedAt":"2009-03-12T18:00:12Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 12 Mar 2009, saurabh gupta wrote:\n\n> On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@pobox.com> wrote:\n>>\n>> You can cut it both ways.  For an OO document, you do not necessarily need\n>> any file-level merger at the driver level, but just let the \"binary\"\n>> driver declare conflicts and punt.  A merge helper can do all the work\n>> starting from the \"original, ours and theirs\" that are not smudged with\n>> conflict markers.\n>>\n>> Between these two extremes, the discussion from other people in the thread\n>> seemed to all focus too heavily on the \"driver punts\" approach, forgetting\n>> that mergetool is useful only because most of the time we do not have to\n>> even use it, thanks to the fact that \"xdl\" driver works reasonably well\n>> for most trivial cases where branches being merged stayed away from each\n>> other, which is the majority case.  It is a huge win from the productivity\n>> point of view, and many people might be unaware of it because it is so\n>> invisible.\n>\n> If I am not wrong, then for merging two xml files, if we use a simple\n> xdl merge driver then it will mark the conflicts in the normal way as\n> it does for simple text files. As far as I can understand, the\n> following things are supposed to be aimed here taking an example of\n> xml file:\n>\n>\n> =>Merging of two xml files\n>\n> => existing merge driver (like xdl) is called which marks the\n> conflicts points just like a normal text file.\n>\n> => the conflicted file can be read through a text terminal and\n> conflicted lines can be seen.\n>\n> => suppose the xml file is from the domain of OO document. Then, a\n> merge helper for OO xml type file is called which takes input as the\n> conflicted file produced by xdl driver.\n>\n> => The merge helper creates a new file or changes the input file to\n> make it a valid xml file so that it can be opened in OpenOffice and\n> user can see the markers like \"====\" or \"<<<<<\"  in an appropriate\n> manner and can resolve the file manually.\n\nwith XML files it's possible to be symanticly identical, but not identical \nas far as a text merge driver is concerned.\n\nfor example, the following two tags are identical in meaning, but would \nshow up as different (and therefor in conflict) in a text merge\n\n\n<tag attr1='foo' attr2='bar' />\n<tag attr2='bar' attr1='foo' />\n\nin many instances (such as config files), the order of items doesn't \nchange the meaning. so the following two items would be identical\n\n<tag1>\n   stuff\n</tag1>\n<tag2>\n   more stuff\n</tag2>\n\nvs\n\n<tag2>\n   more stuff\n</tag2>\n<tag1>\n   stuff>\n</tag1>\n\nin addition whitespace may or may not be relavent (depending on how the \nXML is used) so the following may also be identical\n\n<tag>stuff<tag>\n\nvs\n<tag>\nstuff\n</tag>\n\na good XML merge driver would have options that you could set for a \nparticular file type to know about these sorts of things.\n\n\n>>  When it cannot autoresolve,\n>> but there is no way to \"mark\" a tentative result with conflict markers, it\n>> can do the same thing as the \"binary\" driver and let the mergetool backend\n>> handle the \"driver punted\" case.\n>\n> I think you mean to say that in case, there is a conflict and the\n> changes don't overlap, then merge driver leaves the file as it is and\n> the merge helper will handle the file.\n\nif there is a conflict it should be because the changes do overlap. if \nthey don't overlap why is it a conflict?\n\nDavid Lang"},{"id":"107859","messageId":"alpine.DEB.1.10.0903121100360.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903120542s45b1ceebwddab932891c47cf0@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-12T18:03:47Z","receivedAt":"2009-03-12T18:03:47Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 12 Mar 2009, saurabh gupta wrote:\n\n> hello,\n>\n> On Thu, Mar 12, 2009 at 1:51 AM,  <david@lang.hm> wrote:\n>>\n>>> Yes, but the thing is that the underlying codes and method will be\n>>> different for GUI part and terminal part to make it readable and\n>>> understandable. Like for OO Documents, if we aim to show the *diff*\n>>> output in the Office tool, then we have to change the xml file\n>>> accordingly. But the same xml file when used with terminal only, the\n>>> *diff* output is not clear.\n>>>\n>>> As Johannes said in above post that for OO documents, while showing\n>>> the *diff* result, no xml data should be shown.\n>>\n>> in part we are talking about different aspects of things, and we were all\n>> wrong.\n>>\n>> see the e-mail a little bit ago by Junio\n>>\n>> there are two types of helpers that can be written\n>>\n>> 1. a low-level part that does the simple merges automaticaly and leaves\n>> behind appropriate conflict markers when it can't\n>>\n>> there is no GUI involved with this.\n>>\n>> what 'appropriate conflict markers' are can vary from XML file to XML file\n>>\n>>\n>> 2. after a conflict has taken place, a helper to work with the user to\n>> resolve the conflict\n>>\n>> this can have a GUI and/or a text UI and is tied to the 'appropriate\n>> conflict markers' as defined in #1, and can be _very_ tightly coupled to the\n>> specific use of the XML file.\n>>\n>> I think it's very important to have a text UI tool that can be used for the\n>> conflict resolution step as well as supporting GUI tools.\n>\n> All right. What I can understand from the current situation is that\n> for merging and marking conflicts in xml (for example) files has\n> following things to do.\n>\n> One, if the markers are put in the xml files like that of a text file,\n> one can see the difference using a text editor or a terminal. But if\n> the same xml file is to be opened in another editor which expects a\n> valid xml (as clearly mentioned on the wiki ideas for GIT), then a\n> merge helper is needed.\n>\n> But if the conflict markers are put in a way to make the xml file\n> still valid which can be then opened in the appropriate editor, then\n> the marking will be different. The merge driver has to produce the\n> conflicted merged file in a manner which is still a valid xml file and\n> user has the choice to open it in his own editor to resolve the\n> conflicts.\n\nexactly. and how you mark the conflict to have it be valid XML is going to \ndepend on details of the type of file. there are probably a few basic \nmethods that will work the vast majority of the time, but with some \ndetails needing to be configurable.\n\nfor example, if the XML document is a ODF document, it may be possible to \nadd 'revision' tags around the conflict that are already understood by the \neditor.\n\nDavid Lang\n"},{"id":"107860","messageId":"ab9fa62a0903121123v35004215hbb64f0ad65399d9f@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903121100360.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-12T18:23:41Z","receivedAt":"2009-03-12T18:23:41Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Thu, Mar 12, 2009 at 11:33 PM, <david@lang.hm> wrote:\n>\n> On Thu, 12 Mar 2009, saurabh gupta wrote:\n>\n>> hello,\n>>\n>> On Thu, Mar 12, 2009 at 1:51 AM,  <david@lang.hm> wrote:\n>>>\n>>>> Yes, but the thing is that the underlying codes and method will be\n>>>> different for GUI part and terminal part to make it readable and\n>>>> understandable. Like for OO Documents, if we aim to show the *diff*\n>>>> output in the Office tool, then we have to change the xml file\n>>>> accordingly. But the same xml file when used with terminal only, the\n>>>> *diff* output is not clear.\n>>>>\n>>>> As Johannes said in above post that for OO documents, while showing\n>>>> the *diff* result, no xml data should be shown.\n>>>\n>>> in part we are talking about different aspects of things, and we were all\n>>> wrong.\n>>>\n>>> see the e-mail a little bit ago by Junio\n>>>\n>>> there are two types of helpers that can be written\n>>>\n>>> 1. a low-level part that does the simple merges automaticaly and leaves\n>>> behind appropriate conflict markers when it can't\n>>>\n>>> there is no GUI involved with this.\n>>>\n>>> what 'appropriate conflict markers' are can vary from XML file to XML file\n>>>\n>>>\n>>> 2. after a conflict has taken place, a helper to work with the user to\n>>> resolve the conflict\n>>>\n>>> this can have a GUI and/or a text UI and is tied to the 'appropriate\n>>> conflict markers' as defined in #1, and can be _very_ tightly coupled to the\n>>> specific use of the XML file.\n>>>\n>>> I think it's very important to have a text UI tool that can be used for the\n>>> conflict resolution step as well as supporting GUI tools.\n>>\n>> All right. What I can understand from the current situation is that\n>> for merging and marking conflicts in xml (for example) files has\n>> following things to do.\n>>\n>> One, if the markers are put in the xml files like that of a text file,\n>> one can see the difference using a text editor or a terminal. But if\n>> the same xml file is to be opened in another editor which expects a\n>> valid xml (as clearly mentioned on the wiki ideas for GIT), then a\n>> merge helper is needed.\n>>\n>> But if the conflict markers are put in a way to make the xml file\n>> still valid which can be then opened in the appropriate editor, then\n>> the marking will be different. The merge driver has to produce the\n>> conflicted merged file in a manner which is still a valid xml file and\n>> user has the choice to open it in his own editor to resolve the\n>> conflicts.\n>\n> exactly. and how you mark the conflict to have it be valid XML is going to depend on details of the type of file. there are probably a few basic methods that will work the vast majority of the time, but with some details needing to be configurable.\n>\n> for example, if the XML document is a ODF document, it may be possible to add 'revision' tags around the conflict that are already understood by the editor.\n\nExactly. This includes the work to modify the xml tags and add\ncontents to represent marker in the best way.\n\n\n--\nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107861","messageId":"alpine.DEB.1.10.0903121110400.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"49B90AE4.9030904@drmicha.warpmail.net","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-12T18:25:11Z","receivedAt":"2009-03-12T18:25:11Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 12 Mar 2009, Michael J Gruber wrote:\n\n> Johannes Schindelin venit, vidit, dixit 12.03.2009 14:07:\n>> Hi,\n>>\n>> On Thu, 12 Mar 2009, Michael J Gruber wrote:\n>>\n>>> Johannes Schindelin venit, vidit, dixit 11.03.2009 17:44:\n>>>\n>>>> On Wed, 11 Mar 2009, Daniel Barkalow wrote:\n>>>>\n>>>>> One thing that I think would be good whenever possible is to have the\n>>>>> merge program generate a file in the same format which is easily\n>>>>> recognizable as having conflict markers. For example, I think it\n>>>>> should be possible to show conflicts in the text of office documents\n>>>>> by having styles for each side of the merge, and show each side's\n>>>>> content in the appropriate style. Then the user opens the document\n>>>>> with their choice of office software, finds the things in the\n>>>>> conflict styles, and decides what the result should be.\n>>>> That's a very good idea!  (Except for LaTeX, maybe...)\n>>> latexdiff (in perl) may give you a head start (or ache, I dunno).\n>> No.  latexdiff is about diffing.  It does nothing to help me resolve a\n>> conflict.\n>\n> Sure. If you want to merge you have to diff first (and display it). That\n> would be the \"head start\". Then you have to think about the merge.\n> That's where the \"head ache\" kicks in...\n\nthe idea is that the merge driver should do the diff and merge the simple \nthings, only needing to display it if there is a conflict that it cannot \nresolve.\n\nDavid Lang\n"},{"id":"107863","messageId":"7v1vt2lgyf.fsf@gitster.siamese.dyndns.org","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903121052310.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-12T18:43:52Z","receivedAt":"2009-03-12T18:43:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n> On Thu, 12 Mar 2009, saurabh gupta wrote:\n>\n>> On Thu, Mar 12, 2009 at 3:17 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> ...\n> with XML files it's possible to be symanticly identical, but not\n> identical as far as a text merge driver is concerned.\n> ...\n> a good XML merge driver would have options that you could set for a\n> particular file type to know about these sorts of things.\n\nCorrect.\n\n>>>  When it cannot autoresolve,\n>>> but there is no way to \"mark\" a tentative result with conflict markers, it\n>>> can do the same thing as the \"binary\" driver and let the mergetool backend\n>>> handle the \"driver punted\" case.\n>>\n>> I think you mean to say that in case, there is a conflict and the\n>> changes don't overlap, then merge driver leaves the file as it is and\n>> the merge helper will handle the file.\n>\n> if there is a conflict it should be because the changes do overlap. if\n> they don't overlap why is it a conflict?\n\nCorrect.  In such a case when the \"driver\" can be sure that the result is\nreasonable, \"helper\" should not even kick in.  That was the main point of\nmy suggestion, which you seem to have got right.\n\nThanks.\n"},{"id":"107864","messageId":"alpine.DEB.1.10.0903121148540.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903121119j6c2a1d43kd9cda99db47b5e7c@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-12T18:53:57Z","receivedAt":"2009-03-12T18:53:57Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 12 Mar 2009, saurabh gupta wrote:\n\n> On Thu, Mar 12, 2009 at 11:30 PM, <david@lang.hm> wrote:\n>\n>> On Thu, 12 Mar 2009, saurabh gupta wrote:\n>>\n>>>\n>>> =>Merging of two xml files\n>>>\n>>> => existing merge driver (like xdl) is called which marks the\n>>> conflicts points just like a normal text file.\n>>>\n>>> => the conflicted file can be read through a text terminal and\n>>> conflicted lines can be seen.\n>>>\n>>> => suppose the xml file is from the domain of OO document. Then, a\n>>> merge helper for OO xml type file is called which takes input as the\n>>> conflicted file produced by xdl driver.\n>>>\n>>> => The merge helper creates a new file or changes the input file to\n>>> make it a valid xml file so that it can be opened in OpenOffice and\n>>> user can see the markers like \"====\" or \"<<<<<\"  in an appropriate\n>>> manner and can resolve the file manually.\n>>>\n>>\n>> with XML files it's possible to be symanticly identical, but not identical\n>> as far as a text merge driver is concerned.\n>>\n<SNIPB>\n> you are right. For xml merging, what I am thinking is to create the\n> algorithm based on the document object model. Inside, any tag, all tags are\n> compared only in terms of content and not in order. But again, this ordering\n> option can be given to the user. If the user wants order to matter, then a\n> conflict will be resulted if order mismatches.\n\nright.\n\n> But other issue is regarding the display of conflict markers. Either\n> conflict markers should be put in xml format or like text merger. This is\n> the main project idea for GSoC 2009.\n\nthis may need to be a configurable option, but I suspect that we could get \naway with always using something in XML format. exactly what the markers \nare needs to be configurable (the markers for OO will not be the same as \nfor SVG for example)\n\nbuilding a library of 'this works especially well for this app' markers is \nsomething that needs to be started as part of the GSOC project, but \npossibly only far enough to show a couple of examples and have confidence \nthat the tool is configurable enough.\n\nDavid Lang\n"},{"id":"107865","messageId":"ab9fa62a0903121200v73ec3522gcdebcd34122efc72@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903121148540.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-12T19:00:46Z","receivedAt":"2009-03-12T19:00:46Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Fri, Mar 13, 2009 at 12:23 AM,  <david@lang.hm> wrote:\n> On Thu, 12 Mar 2009, saurabh gupta wrote:\n>\n>> On Thu, Mar 12, 2009 at 11:30 PM, <david@lang.hm> wrote:\n>>\n>>> On Thu, 12 Mar 2009, saurabh gupta wrote:\n>>>\n>>>>\n>>>> =>Merging of two xml files\n>>>>\n>>>> => existing merge driver (like xdl) is called which marks the\n>>>> conflicts points just like a normal text file.\n>>>>\n>>>> => the conflicted file can be read through a text terminal and\n>>>> conflicted lines can be seen.\n>>>>\n>>>> => suppose the xml file is from the domain of OO document. Then, a\n>>>> merge helper for OO xml type file is called which takes input as the\n>>>> conflicted file produced by xdl driver.\n>>>>\n>>>> => The merge helper creates a new file or changes the input file to\n>>>> make it a valid xml file so that it can be opened in OpenOffice and\n>>>> user can see the markers like \"====\" or \"<<<<<\"  in an appropriate\n>>>> manner and can resolve the file manually.\n>>>>\n>>>\n>>> with XML files it's possible to be symanticly identical, but not\n>>> identical\n>>> as far as a text merge driver is concerned.\n>>>\n> <SNIPB>\n>>\n>> you are right. For xml merging, what I am thinking is to create the\n>> algorithm based on the document object model. Inside, any tag, all tags\n>> are\n>> compared only in terms of content and not in order. But again, this\n>> ordering\n>> option can be given to the user. If the user wants order to matter, then a\n>> conflict will be resulted if order mismatches.\n>\n> right.\n>\n>> But other issue is regarding the display of conflict markers. Either\n>> conflict markers should be put in xml format or like text merger. This is\n>> the main project idea for GSoC 2009.\n>\n> this may need to be a configurable option, but I suspect that we could get\n> away with always using something in XML format. exactly what the markers are\n> needs to be configurable (the markers for OO will not be the same as for SVG\n> for example)\n\nyeah.\n\n> building a library of 'this works especially well for this app' markers is\n> something that needs to be started as part of the GSOC project, but possibly\n> only far enough to show a couple of examples and have confidence that the\n> tool is configurable enough.\n>\n\nI think picking up some formats and then building libraries above that\nis needed. In some sense, I talked about the plug-in architecture\nalso. Can;t it be possible that for different applications (like OO or\nSVG), different merge helper plugins are created which can be\nintegrated with it. Or speaking in  other words, instead of plug-ins\nnow, libraries for merge helpers for different applications are\ncreated.\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107875","messageId":"alpine.DEB.1.10.0903121214390.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903121200v73ec3522gcdebcd34122efc72@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-12T19:29:57Z","receivedAt":"2009-03-12T19:29:57Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 13 Mar 2009, saurabh gupta wrote:\n\n> On Fri, Mar 13, 2009 at 12:23 AM,  <david@lang.hm> wrote:\n>> On Thu, 12 Mar 2009, saurabh gupta wrote:\n>>\n>>> On Thu, Mar 12, 2009 at 11:30 PM, <david@lang.hm> wrote:\n>>>\n>>>> On Thu, 12 Mar 2009, saurabh gupta wrote:\n>>>>\n>>>>>\n>>>>> =>Merging of two xml files\n>>>>>\n>>>>> => existing merge driver (like xdl) is called which marks the\n>>>>> conflicts points just like a normal text file.\n>>>>>\n>>>>> => the conflicted file can be read through a text terminal and\n>>>>> conflicted lines can be seen.\n>>>>>\n>>>>> => suppose the xml file is from the domain of OO document. Then, a\n>>>>> merge helper for OO xml type file is called which takes input as the\n>>>>> conflicted file produced by xdl driver.\n>>>>>\n>>>>> => The merge helper creates a new file or changes the input file to\n>>>>> make it a valid xml file so that it can be opened in OpenOffice and\n>>>>> user can see the markers like \"====\" or \"<<<<<\"  in an appropriate\n>>>>> manner and can resolve the file manually.\n>>>>>\n>>>>\n>>>> with XML files it's possible to be symanticly identical, but not\n>>>> identical\n>>>> as far as a text merge driver is concerned.\n>>>>\n>> <SNIPB>\n>>>\n>>> you are right. For xml merging, what I am thinking is to create the\n>>> algorithm based on the document object model. Inside, any tag, all tags\n>>> are\n>>> compared only in terms of content and not in order. But again, this\n>>> ordering\n>>> option can be given to the user. If the user wants order to matter, then a\n>>> conflict will be resulted if order mismatches.\n>>\n>> right.\n>>\n>>> But other issue is regarding the display of conflict markers. Either\n>>> conflict markers should be put in xml format or like text merger. This is\n>>> the main project idea for GSoC 2009.\n>>\n>> this may need to be a configurable option, but I suspect that we could get\n>> away with always using something in XML format. exactly what the markers are\n>> needs to be configurable (the markers for OO will not be the same as for SVG\n>> for example)\n>\n> yeah.\n>\n>> building a library of 'this works especially well for this app' markers is\n>> something that needs to be started as part of the GSOC project, but possibly\n>> only far enough to show a couple of examples and have confidence that the\n>> tool is configurable enough.\n>>\n>\n> I think picking up some formats and then building libraries above that\n> is needed. In some sense, I talked about the plug-in architecture\n> also. Can;t it be possible that for different applications (like OO or\n> SVG), different merge helper plugins are created which can be\n> integrated with it. Or speaking in  other words, instead of plug-ins\n> now, libraries for merge helpers for different applications are\n> created.\n\ndefining terminology that was mentioned before\n\nmerge drivers are run by git to do the merges and create the conflict \nmarkers. git already has a 'plug-in architecture' for these drivers (you \ncan define file types and tell git to use a particular merge driver for \nthis file type)\n\nmerge helpers are run by the users if there is a conflict and make use of \nthe markers. depending on what you end up using for conflict markers, you \nmay not need to write a merge helper (for OO, if your conflict markers are \ngood enough you can use OO to resolve conflicts easily, no need for a new \ntool)\n\n\nwith this terminology, you can't do merge helpers without doing the merge \ndrivers first (what does the helper look for as an indicator of a \nconflict?)\n\nI believe that there is a lot of potential for a configurable merge driver \nto support many similar formats.\n\nusing the example of XML-based files, configurable options could include\n\n1. is the file stored compressed or not\n\n2. does the order of the tags matter\n\n3. does whitespace matter\n\n   note: #2 and #3 may boil down to 'is this a document with XML markup, or \nare the XML tags the primary content'\n\n4. how is the conflict marked\n\n4a. wrap the conflicting tags in a set of tags that look like _\n\n4b. if the conflict is in the content, not the tags, modify it similar to \nwhat we do with text today.\n\n   note: this still requires the new driver to decide if there is a \nconflict or not\n\n4c. other (potentially including calling out to other code for more \ndrastic restructuring)\n\n\nwith a merge driver along these lines you can handle many different types \nof XML documents.\n\nwith SVG you may be able to put the offending tags in different layers\n\nwith OO you may be able to put in tags that indicate a merge conflict in a \nway that OO will directly handle\n\netc.\n\nin many cases you may not even need to create a merge helper or library \nfor other software you use. you just need to figure out what sort of \nmanipulation would need to be done to to file to mark the conflict in a \nway that existing applications can understand.\n\nDavid Lang"},{"id":"107877","messageId":"ab9fa62a0903121245m621643bfq3c58557ccc9b266f@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903121214390.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-12T19:45:23Z","receivedAt":"2009-03-12T19:45:23Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Fri, Mar 13, 2009 at 12:59 AM,  <david@lang.hm> wrote:\n> On Fri, 13 Mar 2009, saurabh gupta wrote:\n>\n> defining terminology that was mentioned before\n>\n> merge drivers are run by git to do the merges and create the conflict\n> markers. git already has a 'plug-in architecture' for these drivers (you can\n> define file types and tell git to use a particular merge driver for this\n> file type)\n>\n> merge helpers are run by the users if there is a conflict and make use of\n> the markers. depending on what you end up using for conflict markers, you\n> may not need to write a merge helper (for OO, if your conflict markers are\n> good enough you can use OO to resolve conflicts easily, no need for a new\n> tool)\n>\n>\n> with this terminology, you can't do merge helpers without doing the merge\n> drivers first (what does the helper look for as an indicator of a conflict?)\n>\n> I believe that there is a lot of potential for a configurable merge driver\n> to support many similar formats.\n>\n> using the example of XML-based files, configurable options could include\n>\n> 1. is the file stored compressed or not\n>\n> 2. does the order of the tags matter\n>\n> 3. does whitespace matter\n>\n>  note: #2 and #3 may boil down to 'is this a document with XML markup, or\n> are the XML tags the primary content'\n>\n> 4. how is the conflict marked\n>\n> 4a. wrap the conflicting tags in a set of tags that look like _\n>\n> 4b. if the conflict is in the content, not the tags, modify it similar to\n> what we do with text today.\n>\n>  note: this still requires the new driver to decide if there is a conflict\n> or not\n>\n> 4c. other (potentially including calling out to other code for more drastic\n> restructuring)\n>\n>\n> with a merge driver along these lines you can handle many different types of\n> XML documents.\n>\n> with SVG you may be able to put the offending tags in different layers\n>\n> with OO you may be able to put in tags that indicate a merge conflict in a\n> way that OO will directly handle\n>\n> etc.\n>\n> in many cases you may not even need to create a merge helper or library for\n> other software you use. you just need to figure out what sort of\n> manipulation would need to be done to to file to mark the conflict in a way\n> that existing applications can understand.\n\nVery well described, David. I agree with you and providing these merge\noptions to the user, merge drivers can do the work and mark the\nconflicts according to the option. The work to do is to modify the\nmerge driver. I think in this way, even people who have only a\nterminal can also gain from it. They can choose the apt option to see\nthe conflict markers in their way. So, the aim is to make merge driver\nconfigurable and create the merged/conflicted file according to the\noptions.\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107878","messageId":"alpine.DEB.1.10.0903121255040.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903121245m621643bfq3c58557ccc9b266f@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-12T19:59:55Z","receivedAt":"2009-03-12T19:59:55Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 13 Mar 2009, saurabh gupta wrote:\n\n> Very well described, David. I agree with you and providing these merge\n> options to the user, merge drivers can do the work and mark the\n> conflicts according to the option. The work to do is to modify the\n> merge driver. I think in this way, even people who have only a\n> terminal can also gain from it. They can choose the apt option to see\n> the conflict markers in their way. So, the aim is to make merge driver\n> configurable and create the merged/conflicted file according to the\n> options.\n\nfor the GSOC I suspect that the right thing to do is the define one or \nmore merge drivers to create, and list what applications are going to be \nused for testing these merges.\n\nyou and the mentor can decide what is a reasonable amount of work.\n\nit may be just doing an XML merge driver is a summer's worth of work, or \nit may be that it's not really enough and you should try to do another one \nor two.\n\nit also may be that there is a lot of overlap between different merge \ndrivers, and once you have the XML driver the others become fairly trivial \nto do. (I'm thinking the config file examples I posted earlier in the \nthread)\n\nDavid Lang\n"},{"id":"107879","messageId":"ab9fa62a0903121303v5a6cbf0ax413cc440b9c32e77@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903121255040.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-12T20:03:56Z","receivedAt":"2009-03-12T20:03:56Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:\n> On Fri, 13 Mar 2009, saurabh gupta wrote:\n>\n>> Very well described, David. I agree with you and providing these merge\n>> options to the user, merge drivers can do the work and mark the\n>> conflicts according to the option. The work to do is to modify the\n>> merge driver. I think in this way, even people who have only a\n>> terminal can also gain from it. They can choose the apt option to see\n>> the conflict markers in their way. So, the aim is to make merge driver\n>> configurable and create the merged/conflicted file according to the\n>> options.\n>\n> for the GSOC I suspect that the right thing to do is the define one or more\n> merge drivers to create, and list what applications are going to be used for\n> testing these merges.\n>\n> you and the mentor can decide what is a reasonable amount of work.\n>\n\nI will very glad to hear about this thing from the mentor (Johannes\nSchindelin, according to wiki). I will try to plan out the things in a\nproper way to carry out this project if I get a chance to work on this\nfor GSoC 2009.\n\n> it may be just doing an XML merge driver is a summer's worth of work, or it\n> may be that it's not really enough and you should try to do another one or\n> two.\n>\n> it also may be that there is a lot of overlap between different merge\n> drivers, and once you have the XML driver the others become fairly trivial\n> to do. (I'm thinking the config file examples I posted earlier in the\n> thread)\n\nwith the options given to the user, one can handle the config files\nalso where order doesn't matter and also the whitespaces problem can\nalso be handled in the similar way.\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107880","messageId":"7vmybqjxzy.fsf@gitster.siamese.dyndns.org","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903121214390.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-03-12T20:18:41Z","receivedAt":"2009-03-12T20:18:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"david@lang.hm writes:\n\n> defining terminology that was mentioned before\n>\n> merge drivers are run by git to do the merges and create the conflict\n> markers. git already has a 'plug-in architecture' for these drivers\n> (you can define file types and tell git to use a particular merge\n> driver for this file type)\n>\n> merge helpers are run by the users if there is a conflict and make use\n> of the markers. depending on what you end up using for conflict\n> markers, you may not need to write a merge helper (for OO, if your\n> conflict markers are good enough you can use OO to resolve conflicts\n> easily, no need for a new tool)\n\nNot really.  A merge helper can look at the stages in the index to get the\n(original, ours, theirs) tuple and start to work from there (and doing a\nhelper as a backend of mergetool will be one way to make it easier), and\nfor such helper the driver does not have to do anything.\n\n> with this terminology, you can't do merge helpers without doing the\n> merge drivers first (what does the helper look for as an indicator of\n> a conflict?)\n\nThe answer to that question is \"the index\", and your \"you can't\" is\ntoo strong.\n\nI agree with you that the original \"editor\" for the specific type of\ndocument (e.g. OOo, inkskape, ...) can be used to fix things up if a\ndriver can leave conflict markers in such a way that the helper does not\nhave to do three-file merge, and that would be a nice thing to have.  But\nfor a helper that can do a real three-file merge (and in this thread I\nthink somebody said OOo can do that), then it is Ok for a driver to punt.\n\nBut even then, *if* there is a driver *and* it can do trivial merges\ncleanly and safely, it would be a huge productivity win, as you do not\nhave to run a helper every time you see two branching touching the same\ndocument even they did so to edit totally unrelated parts of it.\n"},{"id":"107883","messageId":"alpine.DEB.1.10.0903121343590.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"ab9fa62a0903121303v5a6cbf0ax413cc440b9c32e77@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-12T20:45:46Z","receivedAt":"2009-03-12T20:45:46Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 13 Mar 2009, saurabh gupta wrote:\n\n> On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:\n>> On Fri, 13 Mar 2009, saurabh gupta wrote:\n>>\n>>> Very well described, David. I agree with you and providing these merge\n>>> options to the user, merge drivers can do the work and mark the\n>>> conflicts according to the option. The work to do is to modify the\n>>> merge driver. I think in this way, even people who have only a\n>>> terminal can also gain from it. They can choose the apt option to see\n>>> the conflict markers in their way. So, the aim is to make merge driver\n>>> configurable and create the merged/conflicted file according to the\n>>> options.\n>>\n>> for the GSOC I suspect that the right thing to do is the define one or more\n>> merge drivers to create, and list what applications are going to be used for\n>> testing these merges.\n>>\n>> you and the mentor can decide what is a reasonable amount of work.\n>>\n>\n> I will very glad to hear about this thing from the mentor (Johannes\n> Schindelin, according to wiki). I will try to plan out the things in a\n> proper way to carry out this project if I get a chance to work on this\n> for GSoC 2009.\n>\n>> it may be just doing an XML merge driver is a summer's worth of work, or it\n>> may be that it's not really enough and you should try to do another one or\n>> two.\n>>\n>> it also may be that there is a lot of overlap between different merge\n>> drivers, and once you have the XML driver the others become fairly trivial\n>> to do. (I'm thinking the config file examples I posted earlier in the\n>> thread)\n>\n> with the options given to the user, one can handle the config files\n> also where order doesn't matter and also the whitespaces problem can\n> also be handled in the similar way.\n\nwhen I am mentioning config files here I'm thinking of ones that don't use \nXML (such as the git config file)\n\na 'paragraph' merge driver could also help with things like a maintainers \nfile where the order of the paragaphs doesn't matter, just the content \ninside each one.\n\nthat's very similar to re-ordering XML tags, but with a slightly different \nsyntax\n\nDavid Lang\n"},{"id":"107899","messageId":"ab9fa62a0903122015l58c32ca5mfbe1e04e9a2353aa@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903121343590.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-13T03:15:04Z","receivedAt":"2009-03-13T03:15:04Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Fri, Mar 13, 2009 at 2:15 AM,  <david@lang.hm> wrote:\n>\n> when I am mentioning config files here I'm thinking of ones that don't use\n> XML (such as the git config file)\n>\n> a 'paragraph' merge driver could also help with things like a maintainers\n> file where the order of the paragaphs doesn't matter, just the content\n> inside each one.\n>\n> that's very similar to re-ordering XML tags, but with a slightly different\n> syntax\n\nyes, in that case, I think we can modify the existing text merge\ndriver somewhat and provide these configuration options to the user.\nUser can choose the option to configure the merge operation.\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"107919","messageId":"49BA2A4E.3030506@dawes.za.net","threadId":"18261","inReplyTo":"ab9fa62a0903121123v35004215hbb64f0ad65399d9f@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Rogan Dawes","fromEmail":"lists@dawes.za.net","sentAt":"2009-03-13T09:41:34Z","receivedAt":"2009-03-13T09:41:34Z","isPatch":false,"sender":{"key":"lists@dawes.za.net","avatar":null},"body":"saurabh gupta wrote:\n>> exactly. and how you mark the conflict to have it be valid XML is\n>> going to depend on details of the type of file. there are probably\n>> a few basic methods that will work the vast majority of the time,\n>> but with some details needing to be configurable.\n>> \n>> for example, if the XML document is a ODF document, it may be\n>> possible to add 'revision' tags around the conflict that are\n>> already understood by the editor.\n> \n> Exactly. This includes the work to modify the xml tags and add \n> contents to represent marker in the best way.\n\nOn the XML topic, one last thing to keep in mind is the DTD/XSD which\ngoverns the file.\n\nRogan\n"},{"id":"107982","messageId":"ab9fa62a0903131318u47abdc68qefe971bb6d76e8e6@mail.gmail.com","threadId":"18261","inReplyTo":"49BA2A4E.3030506@dawes.za.net","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-13T20:18:04Z","receivedAt":"2009-03-13T20:18:04Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Fri, Mar 13, 2009 at 3:11 PM, Rogan Dawes <lists@dawes.za.net> wrote:\n> saurabh gupta wrote:\n>>> exactly. and how you mark the conflict to have it be valid XML is\n>>> going to depend on details of the type of file. there are probably\n>>> a few basic methods that will work the vast majority of the time,\n>>> but with some details needing to be configurable.\n>>>\n>>> for example, if the XML document is a ODF document, it may be\n>>> possible to add 'revision' tags around the conflict that are\n>>> already understood by the editor.\n>>\n>> Exactly. This includes the work to modify the xml tags and add\n>> contents to represent marker in the best way.\n>\n> On the XML topic, one last thing to keep in mind is the DTD/XSD which\n> governs the file.\n\nThis is another point of thinking. A merge helper changing an xml file\nmay need to modify the schema file also accordingly. Or, by proper\nimplementation, the need of changing the schema file can be escaped.\n:-|\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"108457","messageId":"alpine.DEB.1.00.0903190003100.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"ab9fa62a0903121303v5a6cbf0ax413cc440b9c32e77@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-18T23:16:21Z","receivedAt":"2009-03-18T23:16:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 13 Mar 2009, saurabh gupta wrote:\n\n> On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:\n> > On Fri, 13 Mar 2009, saurabh gupta wrote:\n> >\n> >> Very well described, David. I agree with you and providing these \n> >> merge options to the user, merge drivers can do the work and mark the \n> >> conflicts according to the option. The work to do is to modify the \n> >> merge driver. I think in this way, even people who have only a \n> >> terminal can also gain from it. They can choose the apt option to see \n> >> the conflict markers in their way. So, the aim is to make merge \n> >> driver configurable and create the merged/conflicted file according \n> >> to the options.\n> >\n> > for the GSOC I suspect that the right thing to do is the define one or \n> > more merge drivers to create, and list what applications are going to \n> > be used for testing these merges.\n> >\n> > you and the mentor can decide what is a reasonable amount of work.\n> \n> I will very glad to hear about this thing from the mentor (Johannes \n> Schindelin, according to wiki). I will try to plan out the things in a \n> proper way to carry out this project if I get a chance to work on this \n> for GSoC 2009.\n\nWell, now that we have been accepted as an organization, we can move \nforward with this idea!\n\nMy main concern is that we define early on what should be the user \ninterface, preferably with a quick sketch.\n\nThe technical details, we can hash them out later, I have no doubt that \nwith the help of the complete Git community, we can overcome almost every \nproblem handling XML data or some such.\n\n> > it may be just doing an XML merge driver is a summer's worth of work, \n> > or it may be that it's not really enough and you should try to do \n> > another one or two.\n> >\n> > it also may be that there is a lot of overlap between different merge \n> > drivers, and once you have the XML driver the others become fairly \n> > trivial to do. (I'm thinking the config file examples I posted earlier \n> > in the thread)\n> \n> with the options given to the user, one can handle the config files\n> also where order doesn't matter and also the whitespaces problem can\n> also be handled in the similar way.\n\nIn my humble opinion, we should focus on the data types we want to be \nable to support at the end of the summer first.\n\nFor example, if we decide that OOXML is a must (as it is a proper \nstandard, and many people will benefit from it), we will most likely end \nup in having to write a merge _driver_ (to handle those .zip files), _and_ \na merge _helper_, although we can avoid writing our own GUI, as we can \ncreate an OOXML that has its own version of conflict markers.\n\nIf we decide that SVG is something we want to support by the end of the \nsummer, then we can probably avoid writing a merge _driver_, as plain text \nis handled reasonably well in Git.  OTOH it could turn out that there are \n_real_ conflicts in overlapping tag ids, and it would still be easier to \nwrite a merge driver, too.\n\nIOW the details are not as important as\n\n- knowing what data types we want to support _at the least_, and what data \n  types we keep for the free skate,\n\n- a clear picture of the user interface we want to be able to provide,\n\n- a timeline (weekly milestones should be fine, I guess) what should be \n  achieved when, and\n\n- being flexible in how to support that (IOW if a merge driver appears \n  unnecessary first, but necessary later, we should be able to fit that \n  into both the design and the timeline).\n\nHow does that sound?\n\nCiao,\nDscho\n"},{"id":"108463","messageId":"alpine.DEB.1.10.0903181645440.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903190003100.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-18T23:55:03Z","receivedAt":"2009-03-18T23:55:03Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 19 Mar 2009, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Fri, 13 Mar 2009, saurabh gupta wrote:\n>\n>> On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:\n>>> On Fri, 13 Mar 2009, saurabh gupta wrote:\n>>>\n>>> it may be just doing an XML merge driver is a summer's worth of work,\n>>> or it may be that it's not really enough and you should try to do\n>>> another one or two.\n>>>\n>>> it also may be that there is a lot of overlap between different merge\n>>> drivers, and once you have the XML driver the others become fairly\n>>> trivial to do. (I'm thinking the config file examples I posted earlier\n>>> in the thread)\n>>\n>> with the options given to the user, one can handle the config files\n>> also where order doesn't matter and also the whitespaces problem can\n>> also be handled in the similar way.\n>\n> In my humble opinion, we should focus on the data types we want to be\n> able to support at the end of the summer first.\n>\n> For example, if we decide that OOXML is a must (as it is a proper\n> standard, and many people will benefit from it), we will most likely end\n> up in having to write a merge _driver_ (to handle those .zip files), _and_\n> a merge _helper_, although we can avoid writing our own GUI, as we can\n> create an OOXML that has its own version of conflict markers.\n\ndo you mean OOXML (the microsoft format) or ODF (the open office format)?\n\n> If we decide that SVG is something we want to support by the end of the\n> summer, then we can probably avoid writing a merge _driver_, as plain text\n> is handled reasonably well in Git.  OTOH it could turn out that there are\n> _real_ conflicts in overlapping tag ids, and it would still be easier to\n> write a merge driver, too.\n>\n> IOW the details are not as important as\n>\n> - knowing what data types we want to support _at the least_, and what data\n>  types we keep for the free skate,\n>\n> - a clear picture of the user interface we want to be able to provide,\n>\n> - a timeline (weekly milestones should be fine, I guess) what should be\n>  achieved when, and\n>\n> - being flexible in how to support that (IOW if a merge driver appears\n>  unnecessary first, but necessary later, we should be able to fit that\n>  into both the design and the timeline).\n\nit's up to the student, but I suspect that the best approach would be to \nstart with defining a merge driver to handle XML (with a minimum set of \ncapabilities, and additional optional ones), and go from there.\n\nDavid Lang\n\n> How does that sound?\n>\n> Ciao,\n> Dscho\n>\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"108465","messageId":"alpine.DEB.1.00.0903190141300.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903181645440.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-19T00:43:58Z","receivedAt":"2009-03-19T00:43:58Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 18 Mar 2009, david@lang.hm wrote:\n\n> On Thu, 19 Mar 2009, Johannes Schindelin wrote:\n> \n> > On Fri, 13 Mar 2009, saurabh gupta wrote:\n> >\n> > > On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:\n> > > > On Fri, 13 Mar 2009, saurabh gupta wrote:\n> > > >\n> > > > it may be just doing an XML merge driver is a summer's worth of \n> > > > work, or it may be that it's not really enough and you should try \n> > > > to do another one or two.\n> > > >\n> > > > it also may be that there is a lot of overlap between different \n> > > > merge drivers, and once you have the XML driver the others become \n> > > > fairly trivial to do. (I'm thinking the config file examples I \n> > > > posted earlier in the thread)\n> > >\n> > > with the options given to the user, one can handle the config files \n> > > also where order doesn't matter and also the whitespaces problem can \n> > > also be handled in the similar way.\n> >\n> > In my humble opinion, we should focus on the data types we want to be \n> > able to support at the end of the summer first.\n> >\n> > For example, if we decide that OOXML is a must (as it is a proper \n> > standard, and many people will benefit from it), we will most likely \n> > end up in having to write a merge _driver_ (to handle those .zip \n> > files), _and_ a merge _helper_, although we can avoid writing our own \n> > GUI, as we can create an OOXML that has its own version of conflict \n> > markers.\n> \n> do you mean OOXML (the microsoft format) or ODF (the open office \n> format)?\n\nOops.\n\nEOVERLOAD\n\n> > If we decide that SVG is something we want to support by the end of \n> > the summer, then we can probably avoid writing a merge _driver_, as \n> > plain text is handled reasonably well in Git.  OTOH it could turn out \n> > that there are _real_ conflicts in overlapping tag ids, and it would \n> > still be easier to write a merge driver, too.\n> >\n> > IOW the details are not as important as\n> >\n> > - knowing what data types we want to support _at the least_, and what \n> >   data types we keep for the free skate,\n> >\n> > - a clear picture of the user interface we want to be able to provide,\n> >\n> > - a timeline (weekly milestones should be fine, I guess) what should \n> >   be achieved when, and\n> >\n> > - being flexible in how to support that (IOW if a merge driver appears \n> >   unnecessary first, but necessary later, we should be able to fit \n> >   that into both the design and the timeline).\n> \n> it's up to the student, but I suspect that the best approach would be to \n> start with defining a merge driver to handle XML (with a minimum set of \n> capabilities, and additional optional ones), and go from there.\n\nWell, the thing is: if the student decides to have a go at an XML driver \nfirst and foremost, then I'll just flatly refuse to mentor that.  Because \nI sincerely believe that this project is best designed from top to bottom, \nnot the other way round.\n\nAfter all, the project is based on a user's request, not just a \nplaythingie for an XML enthusiast (if such a thing exists).\n\nCiao,\nDscho\n"},{"id":"108477","messageId":"81bfc67a0903182330q786ef01ai9148e41664a3471a@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903190003100.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2009-03-19T06:30:13Z","receivedAt":"2009-03-19T06:30:13Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"On Wed, Mar 18, 2009 at 7:16 PM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> In my humble opinion, we should focus on the data types we want to be\n> able to support at the end of the summer first.\n\nmy 2 cents don't support xml, support sgml start at the least common\ndenominator and refine from there.\n\n-- \nCaleb Cushing\n\nhttp://xenoterracide.blogspot.com\n"},{"id":"108490","messageId":"alpine.DEB.1.10.0903190129110.4560@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903190141300.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-19T08:37:15Z","receivedAt":"2009-03-19T08:37:15Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 19 Mar 2009, Johannes Schindelin wrote:\n\n> On Wed, 18 Mar 2009, david@lang.hm wrote:\n>\n>> On Thu, 19 Mar 2009, Johannes Schindelin wrote:\n>>\n>>>\n>>> In my humble opinion, we should focus on the data types we want to be\n>>> able to support at the end of the summer first.\n>>>\n>>> For example, if we decide that OOXML is a must (as it is a proper\n>>> standard, and many people will benefit from it), we will most likely\n>>> end up in having to write a merge _driver_ (to handle those .zip\n>>> files), _and_ a merge _helper_, although we can avoid writing our own\n>>> GUI, as we can create an OOXML that has its own version of conflict\n>>> markers.\n>>\n>> do you mean OOXML (the microsoft format) or ODF (the open office\n>> format)?\n>\n> Oops.\n>\n> EOVERLOAD\n\nit happens.\n\n>>> If we decide that SVG is something we want to support by the end of\n>>> the summer, then we can probably avoid writing a merge _driver_, as\n>>> plain text is handled reasonably well in Git.  OTOH it could turn out\n>>> that there are _real_ conflicts in overlapping tag ids, and it would\n>>> still be easier to write a merge driver, too.\n>>>\n>>> IOW the details are not as important as\n>>>\n>>> - knowing what data types we want to support _at the least_, and what\n>>>   data types we keep for the free skate,\n>>>\n>>> - a clear picture of the user interface we want to be able to provide,\n>>>\n>>> - a timeline (weekly milestones should be fine, I guess) what should\n>>>   be achieved when, and\n>>>\n>>> - being flexible in how to support that (IOW if a merge driver appears\n>>>   unnecessary first, but necessary later, we should be able to fit\n>>>   that into both the design and the timeline).\n>>\n>> it's up to the student, but I suspect that the best approach would be to\n>> start with defining a merge driver to handle XML (with a minimum set of\n>> capabilities, and additional optional ones), and go from there.\n>\n> Well, the thing is: if the student decides to have a go at an XML driver\n> first and foremost, then I'll just flatly refuse to mentor that.  Because\n> I sincerely believe that this project is best designed from top to bottom,\n> not the other way round.\n>\n> After all, the project is based on a user's request, not just a\n> playthingie for an XML enthusiast (if such a thing exists).\n\nall three formats mentioned here (OOXML, ODF, SVG) are XML-based formats \nand a single flexible XML merge driver could potentially handle all three \n(as well as other formats). for that matter, the ODF specs cover multiple \ntypes of data, and I suspect that appropriate conflict markers for text \ncould well end up being different than the ones for spreadsheets.\n\nthat's not a 'plaything for an XML entusiast', it's making the tool \nslightly more general than it would need to be for any one of these \nformats to let it handle all of them.\n\n\nbut I'm not a mentor or a student, just an interested user.\n\nDavid Lang\n"},{"id":"108500","messageId":"alpine.DEB.1.00.0903191118210.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"81bfc67a0903182330q786ef01ai9148e41664a3471a@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-19T10:19:09Z","receivedAt":"2009-03-19T10:19:09Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Mar 2009, Caleb Cushing wrote:\n\n> On Wed, Mar 18, 2009 at 7:16 PM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n>\n> > In my humble opinion, we should focus on the data types we want to be \n> > able to support at the end of the summer first.\n> \n> my 2 cents don't support xml, support sgml start at the least common \n> denominator and refine from there.\n\nSorry, by \"data type\" I tried to refer to the nature of the file.  I \nshould have said \"file type\".\n\nCiao,\nDscho\n"},{"id":"108502","messageId":"alpine.DEB.1.00.0903191119340.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903190129110.4560@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-19T10:24:18Z","receivedAt":"2009-03-19T10:24:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Mar 2009, david@lang.hm wrote:\n\n> all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats \n> and a single flexible XML merge driver could potentially handle all \n> three (as well as other formats). for that matter, the ODF specs cover \n> multiple types of data, and I suspect that appropriate conflict markers \n> for text could well end up being different than the ones for \n> spreadsheets.\n\nYou are misunderstanding me.\n\nThe fact that all three are XML based has nothing to do with the _real_ \ngoal of the project.\n\nIOW a user trying to 3-way-merge ODF files could not care less if the \nunderlying technical details involve having an extra merge driver for XML \nfiles or not.\n\nThe user cares about the ease of use, about the user interface.  That is \nwhat I want to focus on.\n\nAnd if we end up with a beautiful XML merge driver at the end of the \nsummer that nobody uses, I will be not only a little disappointed.\n\nSo let's look at the _nature_ of the data at hand, i.e. text, marked-up \ntext, images (we could include UML, which is also XML-based, and where the \nXML merge driver is as relevant for the user experience as for the \nothers), and how to make it _easy_ to resolve merge conflicts there.\n\nCiao,\nDscho\n"},{"id":"108564","messageId":"alpine.DEB.1.10.0903191202480.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903191119340.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-19T19:12:52Z","receivedAt":"2009-03-19T19:12:52Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 19 Mar 2009, Johannes Schindelin wrote:\n\n> On Thu, 19 Mar 2009, david@lang.hm wrote:\n>\n>> all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats\n>> and a single flexible XML merge driver could potentially handle all\n>> three (as well as other formats). for that matter, the ODF specs cover\n>> multiple types of data, and I suspect that appropriate conflict markers\n>> for text could well end up being different than the ones for\n>> spreadsheets.\n>\n> You are misunderstanding me.\n>\n> The fact that all three are XML based has nothing to do with the _real_\n> goal of the project.\n>\n> IOW a user trying to 3-way-merge ODF files could not care less if the\n> underlying technical details involve having an extra merge driver for XML\n> files or not.\n>\n> The user cares about the ease of use, about the user interface.  That is\n> what I want to focus on.\n>\n> And if we end up with a beautiful XML merge driver at the end of the\n> summer that nobody uses, I will be not only a little disappointed.\n>\n> So let's look at the _nature_ of the data at hand, i.e. text, marked-up\n> text, images (we could include UML, which is also XML-based, and where the\n> XML merge driver is as relevant for the user experience as for the\n> others), and how to make it _easy_ to resolve merge conflicts there.\n\nbut don't you want to be able to auto-merge as much as possible before you \nhave to go to _any_ user interaction? (the best user interface is one you \ndon't need to use)\n\nit's only after the merge drive decides that it can't do the merge that \nyou would have to move on to manually resolving conflicts.\n\nwhen you _do_ move on to resolving conflicts, it's not a good approach to \nwrite a GUI tool to deal with each datatype (git does not need it's own \nODF text document editory, spreadsheed editor, graphics editor, etc). it \nmay end up being nessasary for some document types, but that's a last \nresort. it's far better if the conflict markers can be inserted in such a \nway that the normal tools for dealing with that file type can be used.\n\ngit doesn't provide (or mandate) what editor is used to resolve conflicts \nin text files today, it should not do so for other file types either \n(again, except as a last resort)\n\nthe only way to start from the GUI and not create a merge driver first is \nto either have a custom GUI that accepts files 'corrupted' with the \nexisting conflict markers, or work on a GUI that works with both of the \nsources as entire files, with no conflict markers or assistance from git.\n\nDavid Lang\n"},{"id":"108565","messageId":"ab9fa62a0903191217t5d0e6d9cn4915a425ed8084ff@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903190003100.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-19T19:17:24Z","receivedAt":"2009-03-19T19:17:24Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"Hi all,\n\nSorry for replying so late as I was busy in my college's mid-semester exams :-|\n\nOn Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Fri, 13 Mar 2009, saurabh gupta wrote:\n>\n>> On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:\n>> > On Fri, 13 Mar 2009, saurabh gupta wrote:\n>> >\n>> >> Very well described, David. I agree with you and providing these\n>> >> merge options to the user, merge drivers can do the work and mark the\n>> >> conflicts according to the option. The work to do is to modify the\n>> >> merge driver. I think in this way, even people who have only a\n>> >> terminal can also gain from it. They can choose the apt option to see\n>> >> the conflict markers in their way. So, the aim is to make merge\n>> >> driver configurable and create the merged/conflicted file according\n>> >> to the options.\n>> >\n>> > for the GSOC I suspect that the right thing to do is the define one or\n>> > more merge drivers to create, and list what applications are going to\n>> > be used for testing these merges.\n>> >\n>> > you and the mentor can decide what is a reasonable amount of work.\n>>\n>> I will very glad to hear about this thing from the mentor (Johannes\n>> Schindelin, according to wiki). I will try to plan out the things in a\n>> proper way to carry out this project if I get a chance to work on this\n>> for GSoC 2009.\n>\n> Well, now that we have been accepted as an organization, we can move\n> forward with this idea!\n\nCongrats for getting accepted in GSoC 2009.\n\n> My main concern is that we define early on what should be the user\n> interface, preferably with a quick sketch.\n>\n> The technical details, we can hash them out later, I have no doubt that\n> with the help of the complete Git community, we can overcome almost every\n> problem handling XML data or some such.\n>\n>> > it may be just doing an XML merge driver is a summer's worth of work,\n>> > or it may be that it's not really enough and you should try to do\n>> > another one or two.\n>> >\n>> > it also may be that there is a lot of overlap between different merge\n>> > drivers, and once you have the XML driver the others become fairly\n>> > trivial to do. (I'm thinking the config file examples I posted earlier\n>> > in the thread)\n>>\n>> with the options given to the user, one can handle the config files\n>> also where order doesn't matter and also the whitespaces problem can\n>> also be handled in the similar way.\n>\n> In my humble opinion, we should focus on the data types we want to be\n> able to support at the end of the summer first.\n>\n> For example, if we decide that OOXML is a must (as it is a proper\n> standard, and many people will benefit from it), we will most likely end\n> up in having to write a merge _driver_ (to handle those .zip files), _and_\n> a merge _helper_, although we can avoid writing our own GUI, as we can\n> create an OOXML that has its own version of conflict markers.\n\nWell, for ODF type document, we can write a merge driver which will\nchange the xml file in an appropriate way that OO can understand it\nand the user can see the merge result/conflict in a comfortable way.\nAs described by Junio, in this case, a dedicated merge helper is not\nneeded as OO can parse the markers made by merge-driver and provide\nthe user to resolve the conflict and register the changes to index.\n\n\n>\n> If we decide that SVG is something we want to support by the end of the\n> summer, then we can probably avoid writing a merge _driver_, as plain text\n> is handled reasonably well in Git.  OTOH it could turn out that there are\n> _real_ conflicts in overlapping tag ids, and it would still be easier to\n> write a merge driver, too.\n\n>\n> IOW the details are not as important as\n>\n> - knowing what data types we want to support _at the least_, and what data\n>  types we keep for the free skate,\n\nAs of now, how about going for XML files. For this summer, we can go\nfor XML files and latex files can be handled later.\n\n>\n> - a clear picture of the user interface we want to be able to provide,\n\nIn my opinion, we have following things to do:\n\n=> while merging an ODF document, merge-driver will merge the file at\nfile level. If changes don't overlap, then it returns the result with\na success. For example, if the file is changed only on one side, then\nthe driver will simply add the new content.\n\n=> If conflicts appear, then the merge driver will put the markers in\nan appropriate manner which the end-user application (e.g. open\noffice) can understand and show the user. For example, the XML file of\nthat ODF document will be modified and OO can show it  to user in its\nway. We will have to study about the OO style of version marking.\nAnother method is to implement the marker style in our own way. For\nexample, to show any marker, the XML file is modified so that user can\nsee markers like \">>>> \" or \"====\" in openoffice....In this case, we\nwill have to just change the xml content in this way.\n\n>\n> - a timeline (weekly milestones should be fine, I guess) what should be\n>  achieved when, and\n\nTimeline can be decided once we reach some conclusion and the work\nwhich needs to be done become clear to us.\n\n> - being flexible in how to support that (IOW if a merge driver appears\n>  unnecessary first, but necessary later, we should be able to fit that\n>  into both the design and the timeline).\n>\n> How does that sound?\n>\n> Ciao,\n> Dscho\n>\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"108566","messageId":"ab9fa62a0903191223s221269ffs765dd7097ace3f2e@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903190141300.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-19T19:23:15Z","receivedAt":"2009-03-19T19:23:15Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"On Thu, Mar 19, 2009 at 6:13 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Wed, 18 Mar 2009, david@lang.hm wrote:\n>\n>> On Thu, 19 Mar 2009, Johannes Schindelin wrote:\n>>\n>> > On Fri, 13 Mar 2009, saurabh gupta wrote:\n>> >\n>> > > On Fri, Mar 13, 2009 at 1:29 AM,  <david@lang.hm> wrote:\n>> > > > On Fri, 13 Mar 2009, saurabh gupta wrote:\n>> > > >\n>> > > > it may be just doing an XML merge driver is a summer's worth of\n>> > > > work, or it may be that it's not really enough and you should try\n>> > > > to do another one or two.\n>> > > >\n>> > > > it also may be that there is a lot of overlap between different\n>> > > > merge drivers, and once you have the XML driver the others become\n>> > > > fairly trivial to do. (I'm thinking the config file examples I\n>> > > > posted earlier in the thread)\n>> > >\n>> > > with the options given to the user, one can handle the config files\n>> > > also where order doesn't matter and also the whitespaces problem can\n>> > > also be handled in the similar way.\n>> >\n>> > In my humble opinion, we should focus on the data types we want to be\n>> > able to support at the end of the summer first.\n>> >\n>> > For example, if we decide that OOXML is a must (as it is a proper\n>> > standard, and many people will benefit from it), we will most likely\n>> > end up in having to write a merge _driver_ (to handle those .zip\n>> > files), _and_ a merge _helper_, although we can avoid writing our own\n>> > GUI, as we can create an OOXML that has its own version of conflict\n>> > markers.\n>>\n>> do you mean OOXML (the microsoft format) or ODF (the open office\n>> format)?\n>\n> Oops.\n>\n> EOVERLOAD\n>\n>> > If we decide that SVG is something we want to support by the end of\n>> > the summer, then we can probably avoid writing a merge _driver_, as\n>> > plain text is handled reasonably well in Git.  OTOH it could turn out\n>> > that there are _real_ conflicts in overlapping tag ids, and it would\n>> > still be easier to write a merge driver, too.\n>> >\n>> > IOW the details are not as important as\n>> >\n>> > - knowing what data types we want to support _at the least_, and what\n>> >   data types we keep for the free skate,\n>> >\n>> > - a clear picture of the user interface we want to be able to provide,\n>> >\n>> > - a timeline (weekly milestones should be fine, I guess) what should\n>> >   be achieved when, and\n>> >\n>> > - being flexible in how to support that (IOW if a merge driver appears\n>> >   unnecessary first, but necessary later, we should be able to fit\n>> >   that into both the design and the timeline).\n>>\n>> it's up to the student, but I suspect that the best approach would be to\n>> start with defining a merge driver to handle XML (with a minimum set of\n>> capabilities, and additional optional ones), and go from there.\n>\n> Well, the thing is: if the student decides to have a go at an XML driver\n> first and foremost, then I'll just flatly refuse to mentor that.  Because\n> I sincerely believe that this project is best designed from top to bottom,\n> not the other way round.\n>\n> After all, the project is based on a user's request, not just a\n> playthingie for an XML enthusiast (if such a thing exists).\n\nI do agree with you that unless an end user get to see the conflict\nresult in an appropriate manner, there is no use of having an xml\nmerger. But, once we decide as what will be the end file type which we\nwill aim this summer, we can then start working whether its about\nmaking a GUI first, or creating a merge driver first.\n\n\n\n\n> Ciao,\n> Dscho\n>\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"108619","messageId":"alpine.DEB.1.00.0903200034230.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"ab9fa62a0903191217t5d0e6d9cn4915a425ed8084ff@mail.gmail.com","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-19T23:42:40Z","receivedAt":"2009-03-19T23:42:40Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 20 Mar 2009, saurabh gupta wrote:\n\n> On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin\n> <Johannes.Schindelin@gmx.de> wrote:\n>\n> > For example, if we decide that OOXML is a must (as it is a proper \n> > standard, and many people will benefit from it), we will most likely \n> > end up in having to write a merge _driver_ (to handle those .zip \n> > files), _and_ a merge _helper_, although we can avoid writing our own \n> > GUI, as we can create an OOXML that has its own version of conflict \n> > markers.\n> \n> Well, for ODF type document, we can write a merge driver which will \n> change the xml file in an appropriate way that OO can understand it and \n> the user can see the merge result/conflict in a comfortable way. As \n> described by Junio, in this case, a dedicated merge helper is not needed \n> as OO can parse the markers made by merge-driver and provide the user to \n> resolve the conflict and register the changes to index.\n\nThere is also the idea that OOffice has building blocks in place to help \nresolving merge conflicts.  For a successful application, you will have to \nshow that you researched that option, and describe how well/badly it fits \nwith the goal of the project.\n\n> > - knowing what data types we want to support _at the least_, and what \n> >   data  types we keep for the free skate,\n> \n> As of now, how about going for XML files. For this summer, we can go for \n> XML files and latex files can be handled later.\n\nIf your goal is just XML files (without any more specific goal, like ODF \nor SVG), I am afraid that I think that project is not worth 4500 dollar \nfrom Google's pocket.  I mean, we are not talking peanuts here.\n\n> > - a clear picture of the user interface we want to be able to provide,\n> \n> In my opinion, we have following things to do:\n> \n> => while merging an ODF document, merge-driver will merge the file at\n> file level. If changes don't overlap, then it returns the result with\n> a success. For example, if the file is changed only on one side, then\n> the driver will simply add the new content.\n> \n> => If conflicts appear, then the merge driver will put the markers in\n> an appropriate manner which the end-user application (e.g. open\n> office) can understand and show the user. For example, the XML file of\n> that ODF document will be modified and OO can show it  to user in its\n> way. We will have to study about the OO style of version marking.\n> Another method is to implement the marker style in our own way. For\n> example, to show any marker, the XML file is modified so that user can\n> see markers like \">>>> \" or \"====\" in openoffice....In this case, we\n> will have to just change the xml content in this way.\n\nThat is correct, but I would appreciate a bit more definitive research \n_before_ the project proposal, as a sign that you are capable of working \nout the details of the project.\n\n> > - a timeline (weekly milestones should be fine, I guess) what should \n> >   be  achieved when, and\n> \n> Timeline can be decided once we reach some conclusion and the work which \n> needs to be done become clear to us.\n\nLast year, most successful applications detailed a proposed timeline in \ntheir proposal...\n\nDo not get me wrong, I want this project to succeed.\n\nBut on the other hand, I feel the obligation to be a bit demanding for the \ngracious donation of Google: we _do_ want to have something stunningly \nawesome at the end of the summer.\n\nAnd that means that I have to get the impression from the student proposal \nthat something like that is at least _possible_.\n\nCiao,\nDscho\n"},{"id":"108624","messageId":"alpine.DEB.1.10.0903191652500.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903200034230.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-20T00:07:47Z","receivedAt":"2009-03-20T00:07:47Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 20 Mar 2009, Johannes Schindelin wrote:\n\n> Hi,\n>\n> On Fri, 20 Mar 2009, saurabh gupta wrote:\n>\n>> On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin\n>> <Johannes.Schindelin@gmx.de> wrote:\n>>\n>>> For example, if we decide that OOXML is a must (as it is a proper\n>>> standard, and many people will benefit from it), we will most likely\n>>> end up in having to write a merge _driver_ (to handle those .zip\n>>> files), _and_ a merge _helper_, although we can avoid writing our own\n>>> GUI, as we can create an OOXML that has its own version of conflict\n>>> markers.\n>>\n>> Well, for ODF type document, we can write a merge driver which will\n>> change the xml file in an appropriate way that OO can understand it and\n>> the user can see the merge result/conflict in a comfortable way. As\n>> described by Junio, in this case, a dedicated merge helper is not needed\n>> as OO can parse the markers made by merge-driver and provide the user to\n>> resolve the conflict and register the changes to index.\n>\n> There is also the idea that OOffice has building blocks in place to help\n> resolving merge conflicts.  For a successful application, you will have to\n> show that you researched that option, and describe how well/badly it fits\n> with the goal of the project.\n\ntrue, although for the 'simple case' of an ODF text file you can use \ntext strings exactly the same way you do with a text file. the difference \nis that when inserting the two versions of things into the 'conflict' \nversion of the ODF file you need to make sure that you include the \ncomplete open/close set of tags in each version.\n\nfor example if file 1 has\n\n<tag1 param='1'>\ntext\n</tag1>\n\nand file 2 has\n\n<tag1 param='1'>\ntext2\n</tag1>\n\nyou can do\n\n\n<tag1 param='1'>\n>>>>>>>>\ntext\n========\ntext2\n<<<<<<<<\n</tag1>\n\n\nbut if file2 has\n\n\n<tag1 param='2'>\ntext\n</tag1>\n\nyour conflict would need to be\n\n>>>>>>>>\n<tag1 param='1'>\ntext\n</tag1>\n========\n<tag1 param='1'>\ntext\n</tag1>\n<<<<<<<<\n\n(although since < and > are special characters, they would really be &gt \nand &lt in the file)\n\nif there are nicer ways to do this, supporting them would be good, but as \nlong as the marker strings are configurable you can probably do so\n\nyou could change\nthe first string from >>>>>>> to <conflict option='1'>\nthe second string from ======== to </conflict><conflict option='2'>\nthe third string from <<<<<<< to </conflict>\n\nand now instead of having to search for those special text strings, your \nODF editor would 'magicly' identify them and remind you that you hadn't \nresolved all of them.\n\n>>> - knowing what data types we want to support _at the least_, and what\n>>>   data  types we keep for the free skate,\n>>\n>> As of now, how about going for XML files. For this summer, we can go for\n>> XML files and latex files can be handled later.\n>\n> If your goal is just XML files (without any more specific goal, like ODF\n> or SVG), I am afraid that I think that project is not worth 4500 dollar\n> from Google's pocket.  I mean, we are not talking peanuts here.\n\nI see good support for XML being a superset of what's needed to support \nODF or SVG, not a subset.\n\nor another way of putting it, the gitconfig definition for ODF would be a \nshortcut for a longer XML definition with a long list of options.\n\nto be accepted by google, they will need to feel that the work is worth \nthe money, so defining what file types you are going to support is an \nimportant item. This can include saying 'by handling this type of tweak to \nan XML file we can then handle file type Y instead of just file type X \nwith the same merge driver'\n\nas you are considering this list, please think about the items I mentioned \nearlier in the thread that would improve the support for config files and \nmaintainers files (unordered lines/paragraphs)\n\n>>> - a timeline (weekly milestones should be fine, I guess) what should\n>>>   be  achieved when, and\n>>\n>> Timeline can be decided once we reach some conclusion and the work which\n>> needs to be done become clear to us.\n>\n> Last year, most successful applications detailed a proposed timeline in\n> their proposal...\n>\n> Do not get me wrong, I want this project to succeed.\n>\n> But on the other hand, I feel the obligation to be a bit demanding for the\n> gracious donation of Google: we _do_ want to have something stunningly\n> awesome at the end of the summer.\n>\n> And that means that I have to get the impression from the student proposal\n> that something like that is at least _possible_.\n\nsounds reasonable.\n\nDavid Lang"},{"id":"108630","messageId":"alpine.DEB.1.00.0903200128020.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903191652500.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-20T00:30:05Z","receivedAt":"2009-03-20T00:30:05Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Mar 2009, david@lang.hm wrote:\n\n> I see good support for XML being a superset of what's needed to support \n> ODF or SVG, not a subset.\n\nNo, not at all.  If we can get away with the default 3-way merge of Git, \nthe generic XML merge driver be damned.\n\nI'd rather have more file types supported that are useful for the average \nuser, than a generic XML merge driver that is useful to only a handful of \npeople.\n\nCiao,\nDscho\n"},{"id":"108639","messageId":"alpine.DEB.1.10.0903191948050.4560@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903200128020.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-20T03:09:13Z","receivedAt":"2009-03-20T03:09:13Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 20 Mar 2009, Johannes Schindelin wrote:\n\n> On Thu, 19 Mar 2009, david@lang.hm wrote:\n>\n>> I see good support for XML being a superset of what's needed to support\n>> ODF or SVG, not a subset.\n>\n> No, not at all.  If we can get away with the default 3-way merge of Git,\n> the generic XML merge driver be damned.\n\nI would agree, but unless you don't do any auto-merging and punt \neverything to the 'conflict resolution tool' the existing merge drivers \nwon't work for a structured file. And if you do want to do that, it's not \na git project, it's a project for whatever tool you are working from to be \nthe GUI plus (possibly) a smidge of scripting to call that tool from git.\n\n> I'd rather have more file types supported that are useful for the average\n> user, than a generic XML merge driver that is useful to only a handful of\n> people.\n\nwe are both after the same thing, the most use to the average user.\n\nyou look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely \nseperate things that should have support developed seperatly.\n\nI look at the same formats and am seeing a strong similarity between them. \nthat being that they are all structured XML. so if you get the ability to \nhandle XML in a configurable way (and define the appropriate \nconfigurations), you not only get the tools for these things, but many \nothers as well.\n\nI would be a little disappointed if the result of the summer only handled \nXML files (and more so if it only handled a handful of popular XML-based \nfiles). I think that there are a number of file types that aren't handled \nwell by the current merge drivers. Saurabh has voiced the opinion that \nmany of these have similar problems as the XML situations, so it may end \nup making sense to handle them in the same driver.\n\nit would probably be a good thing to see suggestions from a bunch of \npeople as to what file types they see being useful.\n\nDavid Lang\n"},{"id":"108680","messageId":"alpine.DEB.1.00.0903201033310.10279@pacific.mpi-cbg.de","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903191948050.4560@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-03-20T09:35:32Z","receivedAt":"2009-03-20T09:35:32Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 19 Mar 2009, david@lang.hm wrote:\n\n> On Fri, 20 Mar 2009, Johannes Schindelin wrote:\n> \n> > I'd rather have more file types supported that are useful for the \n> > average user, than a generic XML merge driver that is useful to only a \n> > handful of people.\n> \n> we are both after the same thing,\n\nApparently not...\n\n> the most use to the average user.\n> \n> you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely \n> seperate things that should have support developed seperatly.\n\nNo.  I look at SVG, ODF text, ODF spreadsheet, etc as things with \ncompletely different user interfaces.\n\nAnd likewise, the merge _helper_, the very thing the user will get to see, \nmust have different user interfaces.\n\nAnd I see much more potential for this project to fail in those different \nuser interfaces than something as _trivial_ (in relation) as XML merging.\n\nCiao,\nDscho\n"},{"id":"108760","messageId":"alpine.DEB.1.10.0903201337060.16753@asgard.lang.hm","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903201033310.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"","fromEmail":"david@lang.hm","sentAt":"2009-03-20T20:50:24Z","receivedAt":"2009-03-20T20:50:24Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Fri, 20 Mar 2009, Johannes Schindelin wrote:\n\n> On Thu, 19 Mar 2009, david@lang.hm wrote:\n>\n>> On Fri, 20 Mar 2009, Johannes Schindelin wrote:\n>>\n>>> I'd rather have more file types supported that are useful for the\n>>> average user, than a generic XML merge driver that is useful to only a\n>>> handful of people.\n>>\n>> we are both after the same thing,\n>\n> Apparently not...\n>\n>> the most use to the average user.\n>>\n>> you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely\n>> seperate things that should have support developed seperatly.\n>\n> No.  I look at SVG, ODF text, ODF spreadsheet, etc as things with\n> completely different user interfaces.\n>\n> And likewise, the merge _helper_, the very thing the user will get to see,\n> must have different user interfaces.\n\nI absolutly agree with this. the UI and merge _helper_ tools for these \ndifferent file formats are completely different.\n\n> And I see much more potential for this project to fail in those different\n> user interfaces than something as _trivial_ (in relation) as XML merging.\n\nand the key thing that I am saying is that a properly done XML merge may \neliminate the need to do _any_ development of a merge helper tool.\n\nso rather than focusing on what the merge helper tool is going to be and \nwhat the UI for that is, I am focusing on the potential to eliminate any \nneed to hae a specific helper tool by making it so that the marked up \nfiles can be manipulated with the existing tools for that file type.\n\nDavid Lang\n"},{"id":"108802","messageId":"ab9fa62a0903211036v52c671ebx80fa82d9eb974735@mail.gmail.com","threadId":"18261","inReplyTo":"ab9fa62a0903211031l78c7afadg9409a544f2bda7db@mail.gmail.com","subject":"Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-21T17:36:06Z","receivedAt":"2009-03-21T17:36:06Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"hi,\n\nOn Fri, Mar 20, 2009 at 5:12 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Hi,\n>\n> On Fri, 20 Mar 2009, saurabh gupta wrote:\n>\n>> On Thu, Mar 19, 2009 at 4:46 AM, Johannes Schindelin\n>> <Johannes.Schindelin@gmx.de> wrote:\n>>\n>> > For example, if we decide that OOXML is a must (as it is a proper\n>> > standard, and many people will benefit from it), we will most likely\n>> > end up in having to write a merge _driver_ (to handle those .zip\n>> > files), _and_ a merge _helper_, although we can avoid writing our own\n>> > GUI, as we can create an OOXML that has its own version of conflict\n>> > markers.\n>>\n>> Well, for ODF type document, we can write a merge driver which will\n>> change the xml file in an appropriate way that OO can understand it and\n>> the user can see the merge result/conflict in a comfortable way. As\n>> described by Junio, in this case, a dedicated merge helper is not needed\n>> as OO can parse the markers made by merge-driver and provide the user to\n>> resolve the conflict and register the changes to index.\n>\n> There is also the idea that OOffice has building blocks in place to help\n> resolving merge conflicts.  For a successful application, you will have to\n> show that you researched that option, and describe how well/badly it fits\n> with the goal of the project.\n\nExactly, I will have to do some research on it and I will come back to\nyou as I get over with my college's mid-semester exams (this week\nmore).\n\n>> > - knowing what data types we want to support _at the least_, and what\n>> >   data  types we keep for the free skate,\n>>\n>> As of now, how about going for XML files. For this summer, we can go for\n>> XML files and latex files can be handled later.\n>\n> If your goal is just XML files (without any more specific goal, like ODF\n> or SVG), I am afraid that I think that project is not worth 4500 dollar\n> from Google's pocket.  I mean, we are not talking peanuts here.\n\nWell, I didn;t mean to say that we will end up in only having a merge\ndriver for xml after the summer. We will definitely make the driver in\nsuch a way to use the maximum power of xml manipulation so that the\nend application can understand it and user can get the conflict\nresults in a user friendly manner because the end-user application wil\nbe able to parse the merged xml file and will present the conflict\nmarkers in the GUI form.\n\n\n>\n>> > - a clear picture of the user interface we want to be able to provide,\n>>\n>> In my opinion, we have following things to do:\n>>\n>> => while merging an ODF document, merge-driver will merge the file at\n>> file level. If changes don't overlap, then it returns the result with\n>> a success. For example, if the file is changed only on one side, then\n>> the driver will simply add the new content.\n>>\n>> => If conflicts appear, then the merge driver will put the markers in\n>> an appropriate manner which the end-user application (e.g. open\n>> office) can understand and show the user. For example, the XML file of\n>> that ODF document will be modified and OO can show it  to user in its\n>> way. We will have to study about the OO style of version marking.\n>> Another method is to implement the marker style in our own way. For\n>> example, to show any marker, the XML file is modified so that user can\n>> see markers like \">>>> \" or \"====\" in openoffice....In this case, we\n>> will have to just change the xml content in this way.\n>\n> That is correct, but I would appreciate a bit more definitive research\n> _before_ the project proposal, as a sign that you are capable of working\n> out the details of the project.\n\nI do understand your point and will work this.\n\n>> > - a timeline (weekly milestones should be fine, I guess) what should\n>> >   be  achieved when, and\n>>\n>> Timeline can be decided once we reach some conclusion and the work which\n>> needs to be done become clear to us.\n\nI meant to say that time line can decided after the list of works is\ndecided and discussed. Of course, I will present the timeline in my\nstudent application in GSoC 2009. :)\n\n> Do not get me wrong, I want this project to succeed.\n\nI will try my best.\n\n> But on the other hand, I feel the obligation to be a bit demanding for the\n> gracious donation of Google: we _do_ want to have something stunningly\n> awesome at the end of the summer.\n>\n> And that means that I have to get the impression from the student proposal\n> that something like that is at least _possible_.\n>\n> Ciao,\n> Dscho\n>\n\n\n\n--\nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"108803","messageId":"ab9fa62a0903211038x47afc54ek7c3eba2e06458ddd@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.10.0903201337060.16753@asgard.lang.hm","subject":"Re: Google Summer of Code 2009: GIT","fromName":"saurabh gupta","fromEmail":"saurabhgupta1403@gmail.com","sentAt":"2009-03-21T17:38:44Z","receivedAt":"2009-03-21T17:38:44Z","isPatch":false,"sender":{"key":"saurabhgupta1403@gmail.com","avatar":null},"body":"hi,\n\nOn Sat, Mar 21, 2009 at 2:20 AM,  <david@lang.hm> wrote:\n> On Fri, 20 Mar 2009, Johannes Schindelin wrote:\n>\n>> On Thu, 19 Mar 2009, david@lang.hm wrote:\n>>\n>>> On Fri, 20 Mar 2009, Johannes Schindelin wrote:\n>>>\n>>>> I'd rather have more file types supported that are useful for the\n>>>> average user, than a generic XML merge driver that is useful to only a\n>>>> handful of people.\n>>>\n>>> we are both after the same thing,\n>>\n>> Apparently not...\n>>\n>>> the most use to the average user.\n>>>\n>>> you look at SVG, ODF word, ODF spreadsheet, OOXML, etc as completely\n>>> seperate things that should have support developed seperatly.\n>>\n>> No.  I look at SVG, ODF text, ODF spreadsheet, etc as things with\n>> completely different user interfaces.\n>>\n>> And likewise, the merge _helper_, the very thing the user will get to see,\n>> must have different user interfaces.\n>\n> I absolutly agree with this. the UI and merge _helper_ tools for these\n> different file formats are completely different.\n>\n>> And I see much more potential for this project to fail in those different\n>> user interfaces than something as _trivial_ (in relation) as XML merging.\n>\n> and the key thing that I am saying is that a properly done XML merge may\n> eliminate the need to do _any_ development of a merge helper tool.\n\nI also think that if xml file merging is done in a proper way and\naccording to the end-user editor, then it will not be needed to work\non the GUI part. For example, to merge the ODF files, we need to study\nthe merge conflict structure of Openoffice and will have to modify the\nxml file in the same way so that OO can understand it. Similarly for\nother file types.\n\n>\n> so rather than focusing on what the merge helper tool is going to be and\n> what the UI for that is, I am focusing on the potential to eliminate any\n> need to hae a specific helper tool by making it so that the marked up files\n> can be manipulated with the existing tools for that file type.\n>\n> David Lang\n>\n\n\n\n-- \nSaurabh Gupta\nSenior,\nNSIT,New Delhi, India\n"},{"id":"108857","messageId":"81bfc67a0903211653u18b64d45ged863347330d4532@mail.gmail.com","threadId":"18261","inReplyTo":"alpine.DEB.1.00.0903191118210.10279@pacific.mpi-cbg.de","subject":"Re: Google Summer of Code 2009: GIT","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2009-03-21T23:53:36Z","receivedAt":"2009-03-21T23:53:36Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"On Thu, Mar 19, 2009 at 6:19 AM, Johannes Schindelin\n<Johannes.Schindelin@gmx.de> wrote:\n> Sorry, by \"data type\" I tried to refer to the nature of the file.  I\n> should have said \"file type\".\n\nMy concern is that xml will be focused on and html which is not xml\nand yet similar and common will be left out.\n-- \nCaleb Cushing\n\nhttp://xenoterracide.blogspot.com\n"}]}