Hi Junio and Justin
[I'm replying to both of you via Junio's email as you both raised the
same question]
On 21/02/2025 21:31, Junio C Hamano wrote:
"Phillip Wood via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
From: Phillip Wood <phillip.wood@xxxxxxxxxxxxx>
When a hunk is split each of the new hunks inherits whether it is
selected or not from the original hunk. This means that if a selected
hunk is split all of the new hunks are selected and the user is not asked
whether or not they want to select the new hunks. This is unfortunate as
the user is presumably splitting the original hunk because they only
want to select some sub-set of it. Fix this by marking all the new hunks
as "undecided" so that we prompt the user to decide whether to select
them or not.
Good. I am very sure that the design of the current behaviour goes
back to the very original version of "add -p" with hunk splitting I
invented; I simply never considered a workflow where people may
first select and say "oops, let me take it back and redo it". What
I am getting at is that I do not think the current behaviour is
something I designed it to be with too much thought, and debeting if
it makes sense or it would be better to force them to be undecided
is probably a good thing to do now.
Having said that, I have one small concern about forcing them to be
undecided. This now allows it to
1. Add the whole hunk
2. Go back (with K) to that already chosen hunk
3. Split
and makes the resulting minihunks more obvious, as you do not have
to use the uppercase J/K to visit them.
But if one is very used to do this intentionally (as opposed to
"oops, let me take it back"), this would be a usability regression.
"Ah, here is a big hunk with 10 changes, most of which I like, but
one of the lines I do not want to include" in which case I may do
the "Add the hunk to grab 10 changes, visit that decided-to-be-used
hunk, split, and then visit the one minihunk that I want to eject
and say 'n'". This makes the workflow simpler and more stupid by
requiring the 9 minihunks to be chosen individually after splitting.
If the user wants to deselect the 10th mini-hunk then they have to wade
through them all with or without this patch. If they want to deselect an
earlier one then they will now have to do more work.
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.
I can see that in some circumstances this patch does make more work for
the user, but I do think it makes it easier to understand what happens
when hunk is split.
Best Wishes
Phillip
So, I dunno.
