{"thread":{"id":"25245","subject":"custom merge driver vs. CONFLICT (delete/modify)","startedAt":"2010-09-25T20:43:50Z","lastAt":"2010-09-26T14:37:32Z","messageCount":3,"participants":["Sascha Silbe","Jakub Narebski","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"151688","messageId":"1285445444-sup-3857@flatty.sascha.silbe.org","threadId":"25245","inReplyTo":null,"subject":"custom merge driver vs. CONFLICT (delete/modify)","fromName":"Sascha Silbe","fromEmail":"sascha-ml-reply-to-2010-3@silbe.org","sentAt":"2010-09-25T20:43:50Z","receivedAt":"2010-09-25T20:43:50Z","isPatch":false,"sender":{"key":"sascha-ml-reply-to-2010-3@silbe.org","avatar":null},"body":"Hi!\n\nI am (automatically) building snapshot packages by combining the packaging\nmaintained in one repository (but also containing sources) with (more\nrecent) upstream sources from another repository.\n\nFor some files (those touched by rerunning auto*) I want the local\nversion to always take precedence. For some other files (autogen.sh, PO\nfiles) I want the upstream version to take precedence. For all the rest\nI want conflicts to produce an error.\n\nThis has worked fine so far by using custom merge drivers, but while\nadding the second one I encountered a problem: Merge drivers are only\ninvoked for modify/modify (and maybe add/add) conflicts.\nMore specifically a delete/modify conflict will cause git-merge to bail\nout directly without calling the merge driver to resolve the conflict.\nSuch a conflict occurred because the packaging people removed autogen.sh\n(which is reasonable for them, but not for me).\n\nIs there a way to either resolve all kinds of conflicts in favour of\none side (like -X ) or always take one side (like -s ) for\na specific set of files?\nAlternatively, is there a way to do a merge in multiple \"steps\",\noperating only on a subset of the files each time (so I can use\n-s / -X for two of three steps per merge)?\n\nSascha\n\n--\nhttp://sascha.silbe.org/\nhttp://www.infra-silbe.de/\n"},{"id":"151707","messageId":"m38w2ohks3.fsf@localhost.localdomain","threadId":"25245","inReplyTo":"1285445444-sup-3857@flatty.sascha.silbe.org","subject":"Re: custom merge driver vs. CONFLICT (delete/modify)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-26T10:17:19Z","receivedAt":"2010-09-26T10:17:19Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Sascha Silbe writes:\n\n> I am (automatically) building snapshot packages by combining the packaging\n> maintained in one repository (but also containing sources) with (more\n> recent) upstream sources from another repository.\n> \n> For some files (those touched by rerunning auto*) I want the local\n> version to always take precedence. For some other files (autogen.sh, PO\n> files) I want the upstream version to take precedence. For all the rest\n> I want conflicts to produce an error.\n> \n> This has worked fine so far by using custom merge drivers, but while\n> adding the second one I encountered a problem: Merge drivers are only\n> invoked for modify/modify (and maybe add/add) conflicts.\n> More specifically a delete/modify conflict will cause git-merge to bail\n> out directly without calling the merge driver to resolve the conflict.\n> Such a conflict occurred because the packaging people removed autogen.sh\n> (which is reasonable for them, but not for me).\n> \n> Is there a way to either resolve all kinds of conflicts in favour of\n> one side (like -X ) or always take one side (like -s ) for\n> a specific set of files?\n> Alternatively, is there a way to do a merge in multiple \"steps\",\n> operating only on a subset of the files each time (so I can use\n> -s / -X for two of three steps per merge)?\n\nWell, you can create your own merge strategy (see git-merge-ours.sh\nin contrib/examples/ as an example), put it in appropriate place,\nand use '--strategy=' to force using your own custom merge\nstrategy.\n\nThe problem you see is that merge *driver* (as set by gitattributes)\ndeals only with _file-level_ conflicts, i.e. it is run instead of\nordinary diff3-based merge. The CONFLICT(Delete/modify) is solved on\nthe _tree_ level by a merge *strategy*. Currently there is no way to\nchange how tree-level conflict is resolved, without creating your own\nmerge strategy. Though in princile it doesn't seem impossible...\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"151779","messageId":"20100926143732.GA2984@nibiru.local","threadId":"25245","inReplyTo":"1285445444-sup-3857@flatty.sascha.silbe.org","subject":"Re: custom merge driver vs. CONFLICT (delete/modify)","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-09-26T14:37:32Z","receivedAt":"2010-09-26T14:37:32Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Sascha Silbe wrote:\n\nHi,\n\n> For some files (those touched by rerunning auto*) I want the local\n> version to always take precedence. For some other files (autogen.sh, PO\n> files) I want the upstream version to take precedence. For all the rest\n> I want conflicts to produce an error.\n\nPerhaps you better should use an downstream branch (which is frequently\nrebased onto upstream), which removes the autogenerated files and then\nalways regenerate them from scratch. This is what I'm doing in in the\nOSS-QM project [1][2]. I'm also making sure that the source tree\nfollows a set of rules [3] which are IMHO necessary for clean build\nprocess and fix it if needed in my downstream branches.\n \nLooks like we're doing quite similar things - maybe put or efforts\ntogether ? :)\n\n> This has worked fine so far by using custom merge drivers, but while\n> adding the second one I encountered a problem: Merge drivers are only\n> invoked for modify/modify (and maybe add/add) conflicts.\n> More specifically a delete/modify conflict will cause git-merge to bail\n> out directly without calling the merge driver to resolve the conflict.\n\nYes. I've sometimes encountered the same problem. Someone here already\nsuggested using git-filter-branch for that. I'll yet have to investigate\nsuch an transformation process is stable against incremental updates\n(meaning: strictly deterministic - hashes stay the same on repeated\nimports), so the history stays intact.\n\n> Such a conflict occurred because the packaging people removed autogen.sh\n> (which is reasonable for them, but not for me).\n\nIn this case you probably want the conflict, to see what's happening\nand react in a comprehensive way (eg. re-adding it). It could become\neven more interesting when they someday reintroduce it, because maybe\nan autoreconf call won't suffice anymore - in that case you'll also\nwant to know about this, and the conflict is the wakeup call.\n\n> Is there a way to either resolve all kinds of conflicts in favour of\n> one side (like -X ) or always take one side (like -s ) for\n> a specific set of files?\n\nEven if it does not answer your question: maybe this isn't really\nwhat you originally want (go back to the root question: \"what is\nthe real purpose of my project ?\") and makes more trouble than\nwhat you're trying to go around. Perhaps better don't touch these\nfiles at all, but always regenerate them on each build.\n\n\ncu\n\n[1] https://sourceforge.net/p/oss-qm/home/\n[2] http://www.metux.de/download/oss-qm/normalized_repository.pdf\n[3] http://www.metux.de/index.php/de/component/content/article/57.html\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"}]}