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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2009, 02:30 UTC
Message-ID: <7v1vuqdcjp.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <7v1vurf7lq.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> writes:

Show 12 quoted lines

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