From: Junio C Hamano <gitster@pobox.com>
To: Keith Cascio <keith@cs.ucla.edu>
Cc: Jeff King <peff@peff.net>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>,
git@vger.kernel.org
Subject: Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
Date: Sun, 25 Jan 2009 18:30:18 -0800 [thread overview]
Message-ID: <7v1vuqdcjp.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <7v1vurf7lq.fsf@gitster.siamese.dyndns.org> (Junio C. Hamano's message of "Sun, 25 Jan 2009 12:34:09 -0800")
Junio C Hamano <gitster@pobox.com> 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.
next prev parent reply other threads:[~2009-01-26 2:31 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-25 17:30 [PATCH v1 0/3] Introduce config variable "diff.primer" Keith Cascio
2009-01-25 17:30 ` [PATCH v1 1/3] " Keith Cascio
2009-01-25 17:30 ` [PATCH v1 2/3] Test functionality of new " Keith Cascio
2009-01-25 17:30 ` [PATCH v1 3/3] git-gui hooks for " Keith Cascio
2009-01-25 18:22 ` Johannes Schindelin
2009-01-25 18:58 ` Keith Cascio
2009-01-25 18:17 ` [PATCH v1 1/3] Introduce " Johannes Schindelin
2009-01-25 18:44 ` Keith Cascio
2009-01-25 19:30 ` Johannes Schindelin
2009-01-25 20:14 ` Keith Cascio
2009-01-25 22:11 ` Jeff King
2009-01-25 22:58 ` Keith Cascio
2009-01-25 23:25 ` Jeff King
2009-01-25 20:34 ` Junio C Hamano
2009-01-26 2:30 ` Junio C Hamano [this message]
2009-01-26 2:37 ` Keith Cascio
2009-01-26 3:18 ` Jeff King
2009-01-26 3:38 ` Junio C Hamano
2009-01-26 2:40 ` Keith Cascio
2009-01-26 3:12 ` Jeff King
2009-01-26 3:42 ` Junio C Hamano
2009-01-26 3:45 ` Jeff King
2009-01-26 10:54 ` Johannes Schindelin
2009-01-26 11:06 ` Jeff King
2009-01-26 10:59 ` backwards compatibility, was " Johannes Schindelin
2009-01-26 11:16 ` Jeff King
2009-01-26 11:28 ` Johannes Schindelin
2009-01-26 11:59 ` Jeff King
2009-01-27 3:01 ` Keith Cascio
2009-01-26 15:29 ` Jay Soffian
2009-01-26 18:48 ` Jeff King
2009-01-26 19:49 ` Jay Soffian
2009-01-26 20:04 ` Junio C Hamano
2009-01-26 20:32 ` Jay Soffian
2009-01-26 20:35 ` Jeff King
2009-01-26 3:36 ` Junio C Hamano
2009-01-25 20:35 ` [PATCH v1 0/3] " Junio C Hamano
2009-01-25 20:41 ` Keith Cascio
2009-01-25 22:07 ` Jeff King
2009-01-27 1:47 ` Keith Cascio
2009-01-27 4:54 ` Jeff King
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7v1vuqdcjp.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=keith@cs.ucla.edu \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).