{"thread":{"id":"50119","subject":"RFE: version-controlled merge rules","startedAt":"2018-12-27T20:16:16Z","lastAt":"2018-12-29T09:14:41Z","messageCount":7,"participants":["H. Peter Anvin","Jonathan Nieder","Ævar Arnfjörð Bjarmason","Junio C Hamano","Duy Nguyen","hpa@zytor.com"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"365881","messageId":"ad875f1e-54e1-e19f-cd65-95ab503c6de2@zytor.com","threadId":"50119","inReplyTo":null,"subject":"RFE: version-controlled merge rules","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2018-12-27T20:16:07Z","receivedAt":"2018-12-27T20:16:16Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"Right now, merge rules can get selected in .gitattributes, which is\nversion-controlled. However, there does not appear to be any way to *define*\ncustom merge rules which is version controlled.\n\nThere are a lot of different files which can benefit from custom merge rules,\nespecially ones that are in some ways cumulative or version/tree-dependent.\nFor example, I use this rule to merge version files:\n\n[merge \"version\"]\n        name = Version file merge driver\n        driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A\n\n(Incidentally: the need for an explicit temp file here is frustrating. It\nwould be better if git could manage the temporary file. Overwriting %A\ndirectly truncates the file too early.  See other email.)\n\nHowever, I can't even put this in .gitattributes, because doing so would break\nany user who *doesn't* have the previous rule defined locally. Even worse, if\nthis rule needs to change, propagating it to all new users has to be done\nmanually... never mind if it needs to vary by branch!\n\nThe simplest way to address this would presumably be to let the\nrepository/working directory contain a .gitconfig file that can contain rules\nlike that.  (Allowing it to be in the repository proper is probably a\nrequirement for merges to be handled correctly on bare repositories; I'm not\nsure how .gitattributes is handled for that.)\n\n\t-hpa\n"},{"id":"365894","messageId":"20181227235526.GF146609@google.com","threadId":"50119","inReplyTo":"ad875f1e-54e1-e19f-cd65-95ab503c6de2@zytor.com","subject":"Re: RFE: version-controlled merge rules","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2018-12-27T23:55:26Z","receivedAt":"2018-12-27T23:55:31Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nH. Peter Anvin wrote:\n\n> [merge \"version\"]\n>         name = Version file merge driver\n>         driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A\n[...]\n> However, I can't even put this in .gitattributes, because doing so would break\n> any user who *doesn't* have the previous rule defined locally. Even worse, if\n> this rule needs to change, propagating it to all new users has to be done\n> manually... never mind if it needs to vary by branch!\n>\n> The simplest way to address this would presumably be to let the\n> repository/working directory contain a .gitconfig file that can contain rules\n> like that.  (Allowing it to be in the repository proper is probably a\n> requirement for merges to be handled correctly on bare repositories; I'm not\n> sure how .gitattributes is handled for that.)\n\nThe main issue I see is that this would make it a little *too* easy to\nrun arbitrary code on the user's machine.  Build systems often already\nlead to that, but users are more familiar with the risks for build\nthan for version control.\n\nSee [1] for some related discussion.\n\nThat said, using the include.path feature (see git-config(1)), it's\npossible to do something similar:\n\n\t[include]\n\t\tpath = ../.gitconfig\n\nThanks and hope that helps,\nJonathan\n\n[1] https://public-inbox.org/git/20171002234517.GV19555@aiede.mtv.corp.google.com/\n"},{"id":"365897","messageId":"95ca8579-4e12-1e46-8824-b1d19c6d9289@zytor.com","threadId":"50119","inReplyTo":"20181227235526.GF146609@google.com","subject":"Re: RFE: version-controlled merge rules","fromName":"H. Peter Anvin","fromEmail":"hpa@zytor.com","sentAt":"2018-12-28T04:48:06Z","receivedAt":"2018-12-28T04:48:17Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On 12/27/18 3:55 PM, Jonathan Nieder wrote:\n> Hi,\n> \n> H. Peter Anvin wrote:\n> \n>> [merge \"version\"]\n>>         name = Version file merge driver\n>>         driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A\n> [...]\n>> However, I can't even put this in .gitattributes, because doing so would break\n>> any user who *doesn't* have the previous rule defined locally. Even worse, if\n>> this rule needs to change, propagating it to all new users has to be done\n>> manually... never mind if it needs to vary by branch!\n>>\n>> The simplest way to address this would presumably be to let the\n>> repository/working directory contain a .gitconfig file that can contain rules\n>> like that.  (Allowing it to be in the repository proper is probably a\n>> requirement for merges to be handled correctly on bare repositories; I'm not\n>> sure how .gitattributes is handled for that.)\n> \n> The main issue I see is that this would make it a little *too* easy to\n> run arbitrary code on the user's machine.  Build systems often already\n> lead to that, but users are more familiar with the risks for build\n> than for version control.\n> \n> See [1] for some related discussion.\n> \n> That said, using the include.path feature (see git-config(1)), it's\n> possible to do something similar:\n> \n> \t[include]\n> \t\tpath = ../.gitconfig\n> \n> Thanks and hope that helps,\n> Jonathan\n> \n\nThat would be great, except that it doesn't work if the worktree isn't in\n\"..\".  This is one of many cases where it would be great to have environment\nvariable interpolation.\n\n\t-hpa\n\n"},{"id":"365898","messageId":"87muoqdov1.fsf@evledraar.gmail.com","threadId":"50119","inReplyTo":"ad875f1e-54e1-e19f-cd65-95ab503c6de2@zytor.com","subject":"Re: RFE: version-controlled merge rules","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2018-12-28T08:42:10Z","receivedAt":"2018-12-28T08:42:18Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Thu, Dec 27 2018, H. Peter Anvin wrote:\n\n> Right now, merge rules can get selected in .gitattributes, which is\n> version-controlled. However, there does not appear to be any way to *define*\n> custom merge rules which is version controlled.\n>\n> There are a lot of different files which can benefit from custom merge rules,\n> especially ones that are in some ways cumulative or version/tree-dependent.\n> For example, I use this rule to merge version files:\n>\n> [merge \"version\"]\n>         name = Version file merge driver\n>         driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A\n>\n> (Incidentally: the need for an explicit temp file here is frustrating. It\n> would be better if git could manage the temporary file. Overwriting %A\n> directly truncates the file too early.  See other email.)\n>\n> However, I can't even put this in .gitattributes, because doing so would break\n> any user who *doesn't* have the previous rule defined locally. Even worse, if\n> this rule needs to change, propagating it to all new users has to be done\n> manually... never mind if it needs to vary by branch!\n>\n> The simplest way to address this would presumably be to let the\n> repository/working directory contain a .gitconfig file that can contain rules\n> like that.  (Allowing it to be in the repository proper is probably a\n> requirement for merges to be handled correctly on bare repositories; I'm not\n> sure how .gitattributes is handled for that.)\n\nThis would fall under the general umbrella of allowing repos to set\nconfiguration, see\nhttps://public-inbox.org/git/?q=87zi6eakkt.fsf%40evledraar.gmail.com for\nsome previous discussion.\n"},{"id":"365902","messageId":"xmqqo995pvmc.fsf@gitster-ct.c.googlers.com","threadId":"50119","inReplyTo":"20181227235526.GF146609@google.com","subject":"Re: RFE: version-controlled merge rules","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2018-12-28T14:35:23Z","receivedAt":"2018-12-28T14:35:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder <jrnieder@gmail.com> writes:\n\n> The main issue I see is that this would make it a little *too* easy to\n> run arbitrary code on the user's machine.  Build systems often already\n> lead to that, but users are more familiar with the risks for build\n> than for version control.\n>\n> See [1] for some related discussion.\n>\n> That said, using the include.path feature (see git-config(1)), it's\n> possible to do something similar:\n>\n> \t[include]\n> \t\tpath = ../.gitconfig\n>\n> Thanks and hope that helps,\n\nThe issue the arrangement to specify what kind of files they are in\nthe attribute system and to specify what exact commands to be run in\nthe configuration addresses is twofold.  The security issue is one\nand poking a hole with include.path mechanism is probably OK as\nthere is end-user consent, but I tend to agree that a similar risk\nalready exists by a project shipping Makefile et al.\n\nThere is the other side of the issue.\n\nThe arrangement allows project not to be monoculture by leaving the\nexact command sequence to use on the kind of files (specified by the\nproject with the attribute system) up to the end-user in their\nconfiguration.  While Peter may feel that sort piped to head may be\navailable on all the reasonable UNIX systems, his merge driver would\nnot work on other platforms.  There already is a similar reliance of\nmonoculture by a project shipping Makefile et al, which is an\ninteresting parallel.\n"},{"id":"365904","messageId":"CACsJy8A0bP4e14m+zpr02MHCDEBdfpXHn-Vjw5cV4WtQVoKrNg@mail.gmail.com","threadId":"50119","inReplyTo":"95ca8579-4e12-1e46-8824-b1d19c6d9289@zytor.com","subject":"Re: RFE: version-controlled merge rules","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2018-12-28T16:03:40Z","receivedAt":"2018-12-28T16:04:09Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Fri, Dec 28, 2018 at 4:46 PM H. Peter Anvin <hpa@zytor.com> wrote:\n>\n> On 12/27/18 3:55 PM, Jonathan Nieder wrote:\n> > Hi,\n> >\n> > H. Peter Anvin wrote:\n> >\n> >> [merge \"version\"]\n> >>         name = Version file merge driver\n> >>         driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A\n> > [...]\n> >> However, I can't even put this in .gitattributes, because doing so would break\n> >> any user who *doesn't* have the previous rule defined locally. Even worse, if\n> >> this rule needs to change, propagating it to all new users has to be done\n> >> manually... never mind if it needs to vary by branch!\n> >>\n> >> The simplest way to address this would presumably be to let the\n> >> repository/working directory contain a .gitconfig file that can contain rules\n> >> like that.  (Allowing it to be in the repository proper is probably a\n> >> requirement for merges to be handled correctly on bare repositories; I'm not\n> >> sure how .gitattributes is handled for that.)\n> >\n> > The main issue I see is that this would make it a little *too* easy to\n> > run arbitrary code on the user's machine.  Build systems often already\n> > lead to that, but users are more familiar with the risks for build\n> > than for version control.\n> >\n> > See [1] for some related discussion.\n> >\n> > That said, using the include.path feature (see git-config(1)), it's\n> > possible to do something similar:\n> >\n> >       [include]\n> >               path = ../.gitconfig\n> >\n> > Thanks and hope that helps,\n> > Jonathan\n> >\n>\n> That would be great, except that it doesn't work if the worktree isn't in\n> \"..\".  This is one of many cases where it would be great to have environment\n> variable interpolation.\n\nIt's been discussed, see [1] and others in the same thread. The\nfeeling I got was it seemed good idea, but we're just not sure about\nthe exact syntax and some corner cases, and most importantly nobody\nhas stepped up to implement it.\n\n[1] https://public-inbox.org/git/20181109101918.GC7410@sigill.intra.peff.net/\n-- \nDuy\n"},{"id":"365944","messageId":"0F05FF7B-14C7-46C5-A85C-4C571860E8CA@zytor.com","threadId":"50119","inReplyTo":"xmqqo995pvmc.fsf@gitster-ct.c.googlers.com","subject":"Re: RFE: version-controlled merge rules","fromName":"","fromEmail":"hpa@zytor.com","sentAt":"2018-12-29T09:14:24Z","receivedAt":"2018-12-29T09:14:41Z","isPatch":false,"sender":{"key":"hpa@zytor.com","avatar":null},"body":"On December 28, 2018 6:35:23 AM PST, Junio C Hamano <gitster@pobox.com> wrote:\n>Jonathan Nieder <jrnieder@gmail.com> writes:\n>\n>> The main issue I see is that this would make it a little *too* easy\n>to\n>> run arbitrary code on the user's machine.  Build systems often\n>already\n>> lead to that, but users are more familiar with the risks for build\n>> than for version control.\n>>\n>> See [1] for some related discussion.\n>>\n>> That said, using the include.path feature (see git-config(1)), it's\n>> possible to do something similar:\n>>\n>> \t[include]\n>> \t\tpath = ../.gitconfig\n>>\n>> Thanks and hope that helps,\n>\n>The issue the arrangement to specify what kind of files they are in\n>the attribute system and to specify what exact commands to be run in\n>the configuration addresses is twofold.  The security issue is one\n>and poking a hole with include.path mechanism is probably OK as\n>there is end-user consent, but I tend to agree that a similar risk\n>already exists by a project shipping Makefile et al.\n>\n>There is the other side of the issue.\n>\n>The arrangement allows project not to be monoculture by leaving the\n>exact command sequence to use on the kind of files (specified by the\n>project with the attribute system) up to the end-user in their\n>configuration.  While Peter may feel that sort piped to head may be\n>available on all the reasonable UNIX systems, his merge driver would\n>not work on other platforms.  There already is a similar reliance of\n>monoculture by a project shipping Makefile et al, which is an\n>interesting parallel.\n\nThis is actually a further good reason for doing it this way: it means that more genal drivers can be written using files in the repo, depending on what the baseline of the project is.\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.\n"}]}