Re: [Bug report] git diff stat shows unrelated diff

From: Junio C Hamano <gitster@pobox.com>
Date: Feb 18, 2019, 00:21 UTC
Message-ID: <xmqqpnrq2bfg.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <d2127f77-9124-0e01-e96b-b6a1650ebc59@iee.org>

Philip Oakley <philipoakley@iee.org> writes:

Show 5 quoted lines

> It was my understanding that the end point would be total removal of
> any options and the typing of the double dot would be an error. Given
> that hard end point I was looking to ensure that users of double dots
> have a manageable route to unlearning old bad habits. Thus the first
> phase would be opt-in,

Sorry, but I do not see any logical connection in this "Thus". If we are still undecided if deprecating double-dot is a good idea and trying to gauge the impact, then perhaps an early "opt-in" to leave the door open for aborting the transition plan might make sense (as an escape hatch for _us_ the project developers to make excuse to the end users). But I am getting an impression that it is not the plan you have in mind.

Show 5 quoted lines

> To train the fingers, and to check local scripts and aliases, the user
> needs feedback, preferably at a time of their convenience (as opposed
> to being a time of inconvenience), so assuming they have been paying
> moderate attention to the release notes, providing the opt-in phase
> gives them that.

And to those who haven't been paying attention, what happens when your "first phase" period expires?

I would be a lot more sympathetic if your argument were "some people will not be ready to start training, and they will be helped if we had an opt-out knob early in the long deprecation period". Even those who have not been paying attention at all _will_ be hit by deprecation warning, and that is when they can decide if they want to start training or they are not ready and want to postpone, so in that sense, "initial opt-out" may make sense, but I do not see how "initial opt-in" can be a viable thing.