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

[Junio C Hamano <gitster@pobox.com>]

Jay Soffian <jaysoffian@gmail.com> writes:

> On Mon, Jan 26, 2009 at 1:48 PM, Jeff King <peff@peff.net> wrote:
>> But then you have that problem that the _user_ is stuck specifying "OK,
>> turn on fancy features." And I don't relish the thought of typing "git
>> diff -J" every time. :)
>
> Well, this issue seems to come up every so often, so the idea would be:
>
> - We're adding a mechanism for scripts to communicate that they need
> plumbing context
> - Start using it in your scripts when calling git if you rely on a
> stable interface
> - In the next major release, git may introduce changes to commands
> which are not clearly plumbing if you haven't adopted the mechanism

Where do all of these nonsense come from?  We are not adding any mechanism
for scripts to say they need plumbing context.  By calling plumbing they
are already asking for stable plumbing behaviour.

The scripts can, if they want to, use newer options updated versions of
the plumbing commands offer, by passing them when they want to.

And the trigger to do so is up to the scripts.  They can get new options
from the end user, or they can peek into user's configuration variables
similar to the diff.primer mentioned earlier in the discussion.

One way could be a new option --screw-me-with=name that can be given to a
plumbing command and tells it pretend as if the command line options
specified by the configuration variable of the given name were given
(e.g. a script runs "git diff-files --screw-me-with=diff.primer").

The important point is that it has to be opt _IN_.