Re: RFE: version-controlled merge rules

[Junio C Hamano <gitster@pobox.com>]

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.