RFE: version-controlled merge rules

RFE: version-controlled merge rules

[H. Peter Anvin]

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.)

	-hpa

Re: RFE: version-controlled merge rules

[Jonathan Nieder]

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

[1] https://public-inbox.org/git/20171002234517.GV19555@aiede.mtv.corp.google.com/

Re: RFE: version-controlled merge rules

[H. Peter Anvin]

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.

	-hpa

Re: RFE: version-controlled merge rules

[Duy Nguyen]

On Fri, Dec 28, 2018 at 4:46 PM H. Peter Anvin <hpa@zytor.com> wrote:
>
> 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.

It's been discussed, see [1] and others in the same thread. The
feeling I got was it seemed good idea, but we're just not sure about
the exact syntax and some corner cases, and most importantly nobody
has stepped up to implement it.

[1] https://public-inbox.org/git/20181109101918.GC7410@sigill.intra.peff.net/
-- 
Duy

Re: RFE: version-controlled merge rules

[Junio C Hamano]

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.

Re: RFE: version-controlled merge rules

[hpa]

On December 28, 2018 6:35:23 AM PST, Junio C Hamano <gitster@pobox.com> wrote:
>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.

This 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.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: RFE: version-controlled merge rules

[Ævar Arnfjörð Bjarmason]

On Thu, Dec 27 2018, H. Peter Anvin wrote:

> 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.)

This would fall under the general umbrella of allowing repos to set
configuration, see
https://public-inbox.org/git/?q=87zi6eakkt.fsf%40evledraar.gmail.com for
some previous discussion.