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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2009, 03:36 UTC
Message-ID: <7vd4eabuxf.fsf@gitster.siamese.dyndns.org>
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.