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

Philip Oakley [off-list ref] writes:

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.

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.