On 27/02/2025 18:36, Junio C Hamano wrote:
phillip.wood123@xxxxxxxxx writes:
Currently after a selected hunk is split we always prompt the user to
make a decision on the first mini-hunk even though it is marked as
selected when it is split. This seems inconsistent and confused me
when I first tried splitting a selected hunk which is why I wrote this
patch.
Hmph, so there is an obvious alternative "fix" to the inconsistency,
i.e., after splitting, move to the first unselected hunk?
We could do that but I think it would be even more confusing than the
current behavior as it would make it harder to change the state of the
mini-hunks. At least with the current behavior one can use 'J' to move
through them immediately after splitting the original hunk. If we move
to the next undecided hunk one has to know where the newly-created
mini-hunks are relative to that.
True. After all, going back to an already selected hunk and then
splitting the hunk is a clear indication that the user wants to
visit some of them to change their state. Moving them back to
"undecided" (not "deselected") instead of leaving them marked as
"selected" (which is the current behaviour) looks like a better
behaviour and I wish I knew about the possibility in late 2006 when
I added the hunk splitting.
I'm not sure either. I dislike the way it works at the moment and find
it confusing but if there are a lot of people relying on it then I'd
be reluctant to change it.
I share the sentiment, especially the latter.
Unfortunately we don't have any way to know
if anyone is relying on the current behavior without changing it and
seeing if anyone complains. Given it is a bit of a corner case I'm not
sure whether it is worth spending much more time on it.
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.
I'll drop this patch for now. There was some talk a while ago about
adding a mechanism to select "git 3.0" features at build or run time. If
we add something like that I'll resubmit with this change guarded by
that feature.
I can see the problem and asking for conformation before quitting
would have been nice if we'd done it from the start. I'm not sure it
is worth the disruption of changing it when one can re-run "reset/add
-p" quite easily though.
Yup. That matches my assessment of it. I brought it up because I
see this "selection should not stick across splitting" falls into
the same "it would have been nice if it were that way from the
beginning" bucket.
I guess we could add an opt-in cofing that
eventually becomes the default.
I'd prefer not to add configuration for tweaking such a small thing
(this applies to "should selection stick across splitting?", too).
Perhaps we should make the confirm-before-quitting thing a "git 3.0"
feature as well?
Best Wishes
Phillip
While we're talking about tangential issues it would be nice if when a
user revisited a hunk we told them its current state. At the moment
there is no way to tell if a hunk has been selected or not.
The user came back with 'J' or 'K' probably because the hunk was
skipped in their earlier navigation with 'k' or 'j', so users may be
using it as a workaround, but I agree there should be an indicator
for the (unselected, selected, undecided).
Related to that the help for 'J' and 'K' talk about leaving the
current hunk undecided when what they actually do is leave the
current state unchanged.
Nice catch.
Thanks.
