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

From: Junio C Hamano <[email-masked]>
Date: Mon, 15 Sep 2025 10:44:25 -0700

"Phillip Wood via GitGitGadget" <[email-masked]> writes:

> From: Phillip Wood <[email-masked]>
>
> When a hunk is split, each of the new hunks inherits whether it is
> selected or not from the original hunk. If a selected hunk is split
> all of the new hunks are marked as "selected" and the user is only
> prompted with the first of the split hunks. The user is not asked
> whether or not they wish to select the rest of the new hunks. This
> means that if they wish to deselect any of the new hunks apart from
> the first one they have to navigate back to the hunk they want to
> deselect before they can deselect it. This is unfortunate as the user
> is presumably splitting the original hunk because they only want to
> select some sub-set of it.
>
> Instead mark all the new hunks as "undecided" so that the user is
> prompted whether they wish to select each one in turn. In the case
> where the user only wants to change the selection of the first of
> the split hunks they will now have to do more work re-selecting the
> remaining split hunks. However, changing the selection of any of the
> other newly created hunks is now much simpler as the user no-longer has
> to navigate back to them in order to change their selected state.

That is great, but ...

> Due
> to concerns that users may be relying on the current behaviour [1]
> this change is guarded by WITH_BREAKING_CHANGES.

... this does not really sound like a good candidate for "before
version X we used to do this, but after X we no longer do so".

Unless it is a mere bugfix, in which case such a change does not
deserve a huge-version-bump switchover like this.

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?