Re: RFE: version-controlled merge rules

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 28, 2018, 14:35 UTC
Message-ID: <xmqqo995pvmc.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20181227235526.GF146609@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 14 quoted lines

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