Re: [PATCH v2 1/2] add -p: mark split hunks as undecided

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

Phillip Wood <phillip.wood123@gmail.com> writes:

> To me, the current behavior is strange enough to be considered a bug
> but when we discussed this before you were not so sure and said [1]
>
>     Given our user base has grown quite a bit over the years, it
>     almost is a given that any change to existing behaviour is a
>     regression to somebody.  Certainly a safe material for Git 3.0
>     but I do not know if it is safe enough for 2.50 for example.
>     The strategy to leave it longer in 'next' did not work well
>     to catch potential issues for another topic during this cycle,
>     but we could try it out again.
>
> So I re-rolled using WITH_BREAKING_CHANGES. If you're happy just to
> change the behavior unconditionally I can go back to V1

I am *NOT* happy with breaking changes.

Either you cut off those who you do not believe exist because the
behaviour is so strange and useless (i.e. immediate "this is a
bugfix, there is no mechanism to keep the broken behaviour even for
a short period"), which is much better than that from my eyes if I
were to be convinced that the old behaviour is nonsense, or you
support them with configuration without any future deprecation,
which is also fine by me.

The breaking changes mechanism is to be used only when we are
convinced that the old way is nonsense, we are fairly sure that no
sane user is using it, and we have concensus that the old way MUST
be abandoned and any existing users MUST be retrained to use the new
ways, and only to buy/give some time to these users that needs
retraining.

Have we got that firm sense in the community that the old behaviour
qualifies for breaking change mechanism?  I don't, at least not yet.

>> On the other hand, assuming it is not a bugfix but introducing a
>> different behaviour, where both the original and the new ones are
>> useful depending on the situation, wouldn't it be better to give
>> users choices at runtime instead, with a configuration variable at
>> least, but possibly with a interactive command to choose which
>> behaviour is used on demand?
>
> I'm not really convinced the current behavior is that useful and it is
> such an esoteric use of 'add -p' that I'm not sure it makes sense to
> add a config setting for it.

If so, let's break it first and see if anybody screams.  Touching
the breaking changes mechanism is way too early before doing that, I
think.