From: Junio C Hamano <gitster@pobox.com>
To: Keith Cascio <keith@CS.UCLA.EDU>
Cc: git@vger.kernel.org
Subject: Re: [PATCH v1 1/3] Introduce config variable "diff.primer"
Date: Sun, 25 Jan 2009 19:36:12 -0800 [thread overview]
Message-ID: <7vd4eabuxf.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: alpine.GSO.2.00.0901251345240.12651@kiwi.cs.ucla.edu
Keith Cascio <keith@CS.UCLA.EDU> writes:
> I agree opt-in is always better with new grammar/semantics. However, the
> constraint I was trying to live inside is: if I call "git diff" on the command
> line with no options at all
"git diff" is a Porcelain.
> Worth considering: I believe Git users who've written their own scripts are not
> the type to use diff.primer blindly, if at all.
Perhaps this nonsense comes from your misunderstanding on the line between
the plumbing and the Porcelain.
Users of git, including me, would love to be able to use default options
in our $HOME/.gitconfig file when using "git diff" interactively, but will
refuse to see our scripts that we wrote using "git diff-files" and "git
diff-index" broken, because the reason we explicitly used these plumbing
commands is to avoid getting broken with a change from the underlying
version of git. That's the whole point of output stability for the
plumbing.
If you want to be able to use -w or -b (or --color) in git-gui, you must
first vet the script to see if it can sanely operate on the output from
git-diff-index with such options, and after it is determined that it is
safe, it should give its users a way to pass that to the underlying
plumbing, or picked up such options from the configuration (perhaps using
the same diff.primer configuration).
This has to be a conscious opt-in process per script.
next prev parent reply other threads:[~2009-01-26 3:37 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
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 [this message]
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=7vd4eabuxf.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=keith@CS.UCLA.EDU \
/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).