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