Subject: Re: [PATCH v1 1/3] Introduce config variable "diff.primer"

From: Junio C Hamano <[email-masked]>
Date: Sun, 25 Jan 2009 18:30:18 -0800

Junio C Hamano <[email-masked]> writes:

> Scriptability by definition means you do not know how scripts written by
> people around plumbing use the output; I do not think you can sensibly say
> "this should not be turned on in a machine friendly output, but this is
> safe to use".
>
> I would not be opposed to an enhancement to the plumbing that the scripts
> can use to say "I am willing to take any option (or perhaps "these
> options") given to me via diff.primer".  Some scripts may want to be just
> a pass-thru of whatever the underlying git-diff-* command outputs, and it
> may be a handy way to magically upgrade them to allow their invocation of
> lowlevel plumbing to be affected by what the end-user configured.  But
> that magic upgrade has to be an opt/in process.

I suspect it is pretty much orthogonal to the "use user's default without
being told from the command line", but it might be a worthy goal to
introduce a mechanism for the scripts to accept "safe" default options
from the end user while rejecting undesirable ones that would interfere
with the way it uses plumbing.

For example, gitk drives "git rev-list" and many options you give from the
command line (e.g. "gitk --all --simplify-merges -- drivers/") are passed
to the underlying plumbing.

This is a double edged sword.  When we add new features to git-rev-list,
(e.g. --simplify-merges or --simplify-by-decoration are fairly recent
inventions that did not exist when gitk was written originally), some of
them can be safely passed and automagically translates to a new feature in
gitk.  However, use of some options (e.g. --reverse) breaks the assumption
the tool makes on the output from the underlying plumbing and should not
be accepted from the end-user.

It would be a good addition to our toolset if scripts like gitk can
declare which options and features are safe to accept from the end user to
pass down to the plumbing tools.  "git rev-parse", which lets the script
sift between options that are meant to affect ancestry traversal and the
ones that are for other (primarily diff family) commands, does not do
anything fancy like that, but it would be a logical place to do this sort
of thing.

And it is not limited to "scripts" use.  A recent topic on rejecting
colouring options from being given to format-patch would also be helped
with such a mechanism if it is available to builtins.

Just an idle thought.