{"thread":{"id":"7385","subject":"merge strategy request","startedAt":"2007-03-24T22:46:40Z","lastAt":"2007-03-26T00:11:59Z","messageCount":10,"participants":["David Lang","Johannes Schindelin","Linus Torvalds","Junio C Hamano","Martin Langhoff"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"37901","messageId":"Pine.LNX.4.63.0703241430420.12864@qynat.qvtvafvgr.pbz","threadId":"7385","inReplyTo":null,"subject":"merge strategy request","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-03-24T22:46:40Z","receivedAt":"2007-03-24T22:46:40Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"having just gone through a painful manual mere with a config file on a gentoo \nsystem (not useing git) it seems to me that there should be a better way to deal \nwith merging config file updates. I know that gentoo doesn't use git for it's \nconfig files, but I don't think that git would do a whole lot better currently \n(but with access to the history, I think it could)\n\nwhat's happening is\n\nA---B\n \\\n C---D\n\nwhere A and C are the distro maintained config files, B is the one customized \nfor the local system, and D needs to be basicly the same as B, but accounting \nfor the changes between A and C\n\nissues that I see (there are probably others)\n\n1. blank lines and comments are 'uninteresting' changes in that they don't \naffect the result, so if they get botched slightly it doesn't result in a broken \nsystems (although it can cause confusion), what's important are changes ourside \nthe comments. this is especially critical if the version in B strips out \ncomments compared to the sample version in A\n\n2. if B changes a config option and C doesn't (compared to A) then you want to \ngo with what's in B\n\n3. for most config files the order of the options doesn't matter, so look for \nthe same option name out of order.\n\n4. for some config files there are groupings in the config (tags nested inside \nother tags), the nesting is important, even if the order isn't. frequently this \nnesting is indicated by whitespace indentation (or if it's an XML-like config \nfile the nesting can be determined directly from the tags) figuring out exactly \nwaht strategy to use here could be a case of 'try several and see which one \nmakes sense), or it could be that the user needs to identify the strategy to use \nfor a particular file.\n\nthere's been talk about custom merge strategies for different types of files \n(uncompressing office documents to merge them for example), so I think this is \nalong the same lines and wanted to let other people start thinking about the \nproblem and possible solutions.\n\nDavid Lang\n"},{"id":"37908","messageId":"Pine.LNX.4.63.0703241716410.12986@qynat.qvtvafvgr.pbz","threadId":"7385","inReplyTo":"Pine.LNX.4.63.0703250315461.4045@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: merge strategy request","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-03-25T01:18:19Z","receivedAt":"2007-03-25T01:18:19Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Sun, 25 Mar 2007, Johannes Schindelin wrote:\n\n> On Sat, 24 Mar 2007, David Lang wrote:\n>\n>> there's been talk about custom merge strategies for different types of\n>> files (uncompressing office documents to merge them for example), so I\n>> think this is along the same lines and wanted to let other people start\n>> thinking about the problem and possible solutions.\n>\n> There is a nice example script, named git-merge-stupid, which you can\n> use as template.\n>\n> Basically, just write a program named \"git-merge-david-lang\", which takes\n> arguments of the form\n>\n> \tmerge-base [merge-base2...] -- head remote [remote...]\n>\n> IOW, all arguments up to \"--\" are merge bases, and after the \"--\" comes\n> the HEAD and all branches to be merged. All of these argument (except\n> \"--\") are given as commit hashes.\n>\n> IIRC, if no merge bases are passed, the program is expected to find out\n> (basically, take the output of \"git-merge-base --all ...\").\n>\n> And I really prefer _you_ working on it.\n\nI'll add it to my backlog of projects that I'd like to do someday ;-)\n\nunfortunantly it's not likely to be anytime soon (too many things on the list \nahead of it)\n\nDavid Lang\n"},{"id":"37907","messageId":"Pine.LNX.4.63.0703250315461.4045@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7385","inReplyTo":"Pine.LNX.4.63.0703241430420.12864@qynat.qvtvafvgr.pbz","subject":"Re: merge strategy request","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-25T01:20:52Z","receivedAt":"2007-03-25T01:20:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Mar 2007, David Lang wrote:\n\n> there's been talk about custom merge strategies for different types of \n> files (uncompressing office documents to merge them for example), so I \n> think this is along the same lines and wanted to let other people start \n> thinking about the problem and possible solutions.\n\nThere is a nice example script, named git-merge-stupid, which you can \nuse as template.\n\nBasically, just write a program named \"git-merge-david-lang\", which takes \narguments of the form\n\n\tmerge-base [merge-base2...] -- head remote [remote...]\n\nIOW, all arguments up to \"--\" are merge bases, and after the \"--\" comes \nthe HEAD and all branches to be merged. All of these argument (except \n\"--\") are given as commit hashes.\n\nIIRC, if no merge bases are passed, the program is expected to find out \n(basically, take the output of \"git-merge-base --all ...\").\n\nAnd I really prefer _you_ working on it.\n\nCiao,\nDscho\n"},{"id":"37910","messageId":"Pine.LNX.4.64.0703242130050.6730@woody.linux-foundation.org","threadId":"7385","inReplyTo":"Pine.LNX.4.63.0703250315461.4045@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: merge strategy request","fromName":"Linus Torvalds","fromEmail":"torvalds@linux-foundation.org","sentAt":"2007-03-25T04:31:45Z","receivedAt":"2007-03-25T04:31:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Sun, 25 Mar 2007, Johannes Schindelin wrote:\n> \n> Basically, just write a program named \"git-merge-david-lang\", which takes \n> arguments of the form\n> \n> \tmerge-base [merge-base2...] -- head remote [remote...]\n\nI think you are missing what David wants.\n\nDavid does *not* want a new global strategy. Adding those is fairly easy.\n\nDavid seem sto want a new per-file merge strategy, with the bog-standard \nrecursive merge. We've talked about that possibility in the past, but we \ndon't do it now. We always end up doing just the three-way merge.\n\n\t\tLinus\n"},{"id":"37913","messageId":"Pine.LNX.4.63.0703242220510.13287@qynat.qvtvafvgr.pbz","threadId":"7385","inReplyTo":"Pine.LNX.4.64.0703242130050.6730@woody.linux-foundation.org","subject":"Re: merge strategy request","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-03-25T06:25:17Z","receivedAt":"2007-03-25T06:25:17Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Sat, 24 Mar 2007, Linus Torvalds wrote:\n\n> On Sun, 25 Mar 2007, Johannes Schindelin wrote:\n>>\n>> Basically, just write a program named \"git-merge-david-lang\", which takes\n>> arguments of the form\n>>\n>> \tmerge-base [merge-base2...] -- head remote [remote...]\n>\n> I think you are missing what David wants.\n>\n> David does *not* want a new global strategy. Adding those is fairly easy.\n>\n> David seem sto want a new per-file merge strategy, with the bog-standard\n> recursive merge. We've talked about that possibility in the past, but we\n> don't do it now. We always end up doing just the three-way merge.\n\nright, I can see ways to further improve the merge for config files, but they \nwouldn't applty to most other types of files, so it would require support for \nper file merge options.\n\nothers have requested this in the past, this is just one more way that per-file \nmerge options would be useful.\n\nDavid Lang\n"},{"id":"37916","messageId":"7v648paj14.fsf@assigned-by-dhcp.cox.net","threadId":"7385","inReplyTo":"Pine.LNX.4.64.0703242130050.6730@woody.linux-foundation.org","subject":"Re: merge strategy request","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-25T07:17:59Z","receivedAt":"2007-03-25T07:17:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Sun, 25 Mar 2007, Johannes Schindelin wrote:\n>> \n>> Basically, just write a program named \"git-merge-david-lang\", which takes \n>> arguments of the form\n>> \n>> \tmerge-base [merge-base2...] -- head remote [remote...]\n>\n> I think you are missing what David wants.\n>\n> David does *not* want a new global strategy. Adding those is fairly easy.\n>\n> David seems to want a new per-file merge strategy, with the bog-standard \n> recursive merge. We've talked about that possibility in the past, but we \n> don't do it now. We always end up doing just the three-way merge.\n>\n> \t\tLinus\n\nRight. In the current system, git-mergetool might be a better\nplace to add support for special perpose 3-version file-level\nmerge backend than merge-recursive, at least until gitattributes\nmaterializes.\n"},{"id":"37976","messageId":"Pine.LNX.4.63.0703251514060.13765@qynat.qvtvafvgr.pbz","threadId":"7385","inReplyTo":"46a038f90703251634t2ab6a455t382ebe29cdb53667@mail.gmail.com","subject":"Re: merge strategy request","fromName":"David Lang","fromEmail":"david.lang@digitalinsight.com","sentAt":"2007-03-25T23:16:26Z","receivedAt":"2007-03-25T23:16:26Z","isPatch":false,"sender":{"key":"david.lang@digitalinsight.com","avatar":null},"body":"On Mon, 26 Mar 2007, Martin Langhoff wrote:\n\n> On 3/25/07, Junio C Hamano wrote:\n>> Right. In the current system, git-mergetool might be a better\n>> place to add support for special perpose 3-version file-level\n>> merge backend than merge-recursive, at least until gitattributes\n>> materializes.\n>\n> Would it be possible to have an env var (GIT_MERGE) that can be used\n> to call an arbitrary script with merge/diff3 semantics instead of\n> using the internal 3-way merge? That way we could do syntax-specific\n> merges (ignore comments/whitespace, for example).\n>\n> i would surely have a use for it, as sometimes my internal team is not\n> _that_ good about trimming whitespace, and we have merges that succeed\n> except for their whitespace conflicts.\n\nwould you really want that for _all_ merges, or only for merges of specific file \ntypes?\n\nif you want it for all merges you should be able to create a modified version of \nthe current merge and just substatute it in your install.\n\nif you want it only for specific file types (say .c, .h, and .cfg files) then \nyou really want the gitattributes support.\n\ndid anyone jump in on that for a soc project?\n\nDavid Lang\n"},{"id":"37972","messageId":"46a038f90703251634t2ab6a455t382ebe29cdb53667@mail.gmail.com","threadId":"7385","inReplyTo":"7v648paj14.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge strategy request","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-03-25T23:34:29Z","receivedAt":"2007-03-25T23:34:29Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/25/07, Junio C Hamano wrote:\n> Right. In the current system, git-mergetool might be a better\n> place to add support for special perpose 3-version file-level\n> merge backend than merge-recursive, at least until gitattributes\n> materializes.\n\nWould it be possible to have an env var (GIT_MERGE) that can be used\nto call an arbitrary script with merge/diff3 semantics instead of\nusing the internal 3-way merge? That way we could do syntax-specific\nmerges (ignore comments/whitespace, for example).\n\ni would surely have a use for it, as sometimes my internal team is not\n_that_ good about trimming whitespace, and we have merges that succeed\nexcept for their whitespace conflicts.\n\ncheers,\n\n\n\nmartin\n"},{"id":"37977","messageId":"7vejnc28i3.fsf@assigned-by-dhcp.cox.net","threadId":"7385","inReplyTo":"46a038f90703251634t2ab6a455t382ebe29cdb53667@mail.gmail.com","subject":"Re: merge strategy request","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-03-25T23:44:52Z","receivedAt":"2007-03-25T23:44:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Martin Langhoff\" writes:\n\n> Would it be possible to have an env var (GIT_MERGE) that can be used\n> to call an arbitrary script with merge/diff3 semantics instead of\n> using the internal 3-way merge? That way we could do syntax-specific\n> merges (ignore comments/whitespace, for example).\n\nI do not think such a patch is hard, as calling external merge\nfor file-level merge is what we used to do. It's just a matter\nof resurrecting the code we threw away and making it be called\nconditionally.\n\nBut a more interesting point is \"under what condition\". If the\ncondition is \"when GIT_MERGE environment is defined\", it is not\nmuch better than what Dscho suggested, as the external merger\nwould be called for all paths. We would want a mechanism to\ndecide use of such a specialized merge backend for special\ncases, which is where gitattributes comes into the picture.\nEspecially because there would be one specialized to merge xml\ndocuments, one to merge gimp xcf files, and another to merge\ngentoo configuration files (or whatever the original thread\nstarter wanted).\n\n> i would surely have a use for it, as sometimes my internal team is not\n> _that_ good about trimming whitespace, and we have merges that succeed\n> except for their whitespace conflicts.\n\nI know Linus does not like applying patches with whitespace\nfuzziness, but I personally think a merge that ignores\nwhitespace changes would be a useful thing to have, without\nhaving to call an external specialized merge backend. In other\nwords, I do not think it is so special a thing to want to, but\nit is rather an unfortunate norm. I am not opposed to give\ngit-merge-recursive a command line option to tell it to merge\nignoring the whitespace-only changes, when it does the 3-way\nfile-level merge internally.\n\nThere is a small detail of how to pass such a command line\noption to git-merge-$strategy backends, though.\n"},{"id":"37978","messageId":"46a038f90703251711x6ecfa3e2k19b7d36717fad44e@mail.gmail.com","threadId":"7385","inReplyTo":"7vejnc28i3.fsf@assigned-by-dhcp.cox.net","subject":"Re: merge strategy request","fromName":"Martin Langhoff","fromEmail":"martin.langhoff@gmail.com","sentAt":"2007-03-26T00:11:59Z","receivedAt":"2007-03-26T00:11:59Z","isPatch":false,"sender":{"key":"martin.langhoff@gmail.com","avatar":"https://gravatar.com/avatar/1e3f311b6c4c15836501901ca58f8c0b0667246488084ba524d8bc9867e22fd9?d=mp&s=160"},"body":"On 3/26/07, Junio C Hamano wrote:\n> But a more interesting point is \"under what condition\". If the\n> condition is \"when GIT_MERGE environment is defined\", it is not\n> much better than what Dscho suggested, as the external merger\n> would be called for all paths.\n\nWell well... no. Unless you mean all paths that need diff3 merging\n(that is, all paths that changed on both sides). And in that case, the\nscript itself can have the \"change policy depending on file extension\nor phase of the moon\" machinery. I think it makes it more powerful\nbecause it can have specialised logic for this -- where the git\nmachinery is going to be limited to simpler rules (like file\nextension).\n\nIn any case, it is a _different_ mechanism to saying \"all changed\npaths on either side\". I don't know if there is even an interesting\ncase for that.\n\n> it is rather an unfortunate norm. I am not opposed to give\n> git-merge-recursive a command line option to tell it to merge\n> ignoring the whitespace-only changes, when it does the 3-way\n> file-level merge internally.\n\nThat'd be great to have. How about both? ;-)\n\ncheers,\n\n\nm\n"}]}