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

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 26, 2009, 20:04 UTC
Message-ID: <7vd4e96dh7.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <76718490901261149xfedc415j8f5dab677b90d693@mail.gmail.com>

Jay Soffian <jaysoffian@gmail.com> writes:

Show 13 quoted lines

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