Re: [PATCH v2 1/2] add -p: mark split hunks as undecided
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Sep 15, 2025, 17:44 UTC
- Message-ID
- <xmqqbjnbhapy.fsf@gitster.g>
- In-Reply-To
- <3e2ec7b37f1935c5b091fc4b47b6209beb384d3a.1757950144.git.gitgitgadget@gmail.com>
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 20 quoted lines
> From: Phillip Wood <phillip.wood@dunelm.org.uk> > > 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?