From: Junio C Hamano Date: Mon, 15 Sep 2025 17:44:25 GMT Subject: Re: [PATCH v2 1/2] add -p: mark split hunks as undecided Message-ID: In-Reply-To: <3e2ec7b37f1935c5b091fc4b47b6209beb384d3a.1757950144.git.gitgitgadget@gmail.com> "Phillip Wood via GitGitGadget" writes: > From: Phillip Wood > > 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?