RFE: version-controlled merge rules

> However, I can't even put this in .gitattributes, because doing so would break
> any user who *doesn't* have the previous rule defined locally. Even worse, if
> this rule needs to change, propagating it to all new users has to be done
> manually... never mind if it needs to vary by branch!
>
> The simplest way to address this would presumably be to let the
> repository/working directory contain a .gitconfig file that can contain rules
> like that.  (Allowing it to be in the repository proper is probably a
> requirement for merges to be handled correctly on bare repositories; I'm not
> sure how .gitattributes is handled for that.)

> Hi,
> 
> H. Peter Anvin wrote:
> 
>> [merge "version"]
>>         name = Version file merge driver
>>         driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A
> [...]
>> However, I can't even put this in .gitattributes, because doing so would break
>> any user who *doesn't* have the previous rule defined locally. Even worse, if
>> this rule needs to change, propagating it to all new users has to be done
>> manually... never mind if it needs to vary by branch!
>>
>> The simplest way to address this would presumably be to let the
>> repository/working directory contain a .gitconfig file that can contain rules
>> like that.  (Allowing it to be in the repository proper is probably a
>> requirement for merges to be handled correctly on bare repositories; I'm not
>> sure how .gitattributes is handled for that.)
> 
> The main issue I see is that this would make it a little *too* easy to
> run arbitrary code on the user's machine.  Build systems often already
> lead to that, but users are more familiar with the risks for build
> than for version control.
> 
> See [1] for some related discussion.
> 
> That said, using the include.path feature (see git-config(1)), it's
> possible to do something similar:
> 
> 	[include]
> 		path = ../.gitconfig
> 
> Thanks and hope that helps,
> Jonathan
> 

>
> On 12/27/18 3:55 PM, Jonathan Nieder wrote:
> > Hi,
> >
> > H. Peter Anvin wrote:
> >
> >> [merge "version"]
> >>         name = Version file merge driver
> >>         driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A
> > [...]
> >> However, I can't even put this in .gitattributes, because doing so would break
> >> any user who *doesn't* have the previous rule defined locally. Even worse, if
> >> this rule needs to change, propagating it to all new users has to be done
> >> manually... never mind if it needs to vary by branch!
> >>
> >> The simplest way to address this would presumably be to let the
> >> repository/working directory contain a .gitconfig file that can contain rules
> >> like that.  (Allowing it to be in the repository proper is probably a
> >> requirement for merges to be handled correctly on bare repositories; I'm not
> >> sure how .gitattributes is handled for that.)
> >
> > The main issue I see is that this would make it a little *too* easy to
> > run arbitrary code on the user's machine.  Build systems often already
> > lead to that, but users are more familiar with the risks for build
> > than for version control.
> >
> > See [1] for some related discussion.
> >
> > That said, using the include.path feature (see git-config(1)), it's
> > possible to do something similar:
> >
> >       [include]
> >               path = ../.gitconfig
> >
> > Thanks and hope that helps,
> > Jonathan
> >
>
> That would be great, except that it doesn't work if the worktree isn't in
> "..".  This is one of many cases where it would be great to have environment
> variable interpolation.

> The main issue I see is that this would make it a little *too* easy to
> run arbitrary code on the user's machine.  Build systems often already
> lead to that, but users are more familiar with the risks for build
> than for version control.
>
> See [1] for some related discussion.
>
> That said, using the include.path feature (see git-config(1)), it's
> possible to do something similar:
>
> 	[include]
> 		path = ../.gitconfig
>
> Thanks and hope that helps,

>Jonathan Nieder <jrnieder@gmail.com> writes:
>
>> The main issue I see is that this would make it a little *too* easy
>to
>> run arbitrary code on the user's machine.  Build systems often
>already
>> lead to that, but users are more familiar with the risks for build
>> than for version control.
>>
>> See [1] for some related discussion.
>>
>> That said, using the include.path feature (see git-config(1)), it's
>> possible to do something similar:
>>
>> 	[include]
>> 		path = ../.gitconfig
>>
>> Thanks and hope that helps,
>
>The issue the arrangement to specify what kind of files they are in
>the attribute system and to specify what exact commands to be run in
>the configuration addresses is twofold.  The security issue is one
>and poking a hole with include.path mechanism is probably OK as
>there is end-user consent, but I tend to agree that a similar risk
>already exists by a project shipping Makefile et al.
>
>There is the other side of the issue.
>
>The arrangement allows project not to be monoculture by leaving the
>exact command sequence to use on the kind of files (specified by the
>project with the attribute system) up to the end-user in their
>configuration.  While Peter may feel that sort piped to head may be
>available on all the reasonable UNIX systems, his merge driver would
>not work on other platforms.  There already is a similar reliance of
>monoculture by a project shipping Makefile et al, which is an
>interesting parallel.

> Right now, merge rules can get selected in .gitattributes, which is
> version-controlled. However, there does not appear to be any way to *define*
> custom merge rules which is version controlled.
>
> There are a lot of different files which can benefit from custom merge rules,
> especially ones that are in some ways cumulative or version/tree-dependent.
> For example, I use this rule to merge version files:
>
> [merge "version"]
>         name = Version file merge driver
>         driver = sort -V -r %O %A %B | head -1 > %A.tmp.1 && mv -f %A.tmp.1 %A
>
> (Incidentally: the need for an explicit temp file here is frustrating. It
> would be better if git could manage the temporary file. Overwriting %A
> directly truncates the file too early.  See other email.)
>
> However, I can't even put this in .gitattributes, because doing so would break
> any user who *doesn't* have the previous rule defined locally. Even worse, if
> this rule needs to change, propagating it to all new users has to be done
> manually... never mind if it needs to vary by branch!
>
> The simplest way to address this would presumably be to let the
> repository/working directory contain a .gitconfig file that can contain rules
> like that.  (Allowing it to be in the repository proper is probably a
> requirement for merges to be handled correctly on bare repositories; I'm not
> sure how .gitattributes is handled for that.)