Samuel Abraham [off-list ref] writes:
quoted
I am not sure if I would like the end result or rather prefer your
"all-or-none", so please do not take this as "here is a better way
to implement it" suggestion.
But you should be able to keep the current semantics, if you wanted
to, even if you apply the chosen hunks when you switch files, like
the original code has been doing forever since it was written. You
know which hunks you applied, so after applying before moving on to
the next file, you can drop these hunks from the list of hunks to be
decided for application. When the user comes back to the current
file to decide on other hunks, you know that the already used hunks
would get in the way, so why keep them?
Yes thank you so much for suggesting this approach.
Not so fast. I explicitly said I am *NOT* suggesting anything.
And thinking about it more, I do not think it makes any sense to do
anything other than "all-or-none" when the command is working in
your new "you can move to different files before you decide on all
hunks in the current file" mode (which I think we agreed to make it
an optional mode). Why? After deciding yes, no, no among 5 hunks
in the first file (leaving the hunks #4 and #5 undecided), you jump
to the second file, do something there, and imagine that you come
back. If we drop the alrady applied hunks like the suggestion,
which I did not make ;-), we'd then give you four hunks (as hunk #1
has been already applied), and even though you have already decided
not to use hunks #2 and #3, you *can* revisit them with "J" or "K",
change your mind and use them if you wanted to. But it is too late
for the hunk #1. It looks utterly inconsistent if you cannot change
your mind on hunk #1 but can on hunks #2 and #3 and it reduces the
usefulness of "you do not have to decide right now and visit other
files before you do so" mode.
Thanks.
On Mon, Feb 2, 2026 at 6:26 PM Junio C Hamano [off-list ref] wrote:
Samuel Abraham [off-list ref] writes:
quoted
quoted
I am not sure if I would like the end result or rather prefer your
"all-or-none", so please do not take this as "here is a better way
to implement it" suggestion.
But you should be able to keep the current semantics, if you wanted
to, even if you apply the chosen hunks when you switch files, like
the original code has been doing forever since it was written. You
know which hunks you applied, so after applying before moving on to
the next file, you can drop these hunks from the list of hunks to be
decided for application. When the user comes back to the current
file to decide on other hunks, you know that the already used hunks
would get in the way, so why keep them?
Yes thank you so much for suggesting this approach.
Not so fast. I explicitly said I am *NOT* suggesting anything.
Yes you did.
And thinking about it more, I do not think it makes any sense to do
anything other than "all-or-none" when the command is working in
your new "you can move to different files before you decide on all
hunks in the current file" mode (which I think we agreed to make it
an optional mode). Why? After deciding yes, no, no among 5 hunks
in the first file (leaving the hunks #4 and #5 undecided), you jump
to the second file, do something there, and imagine that you come
back. If we drop the alrady applied hunks like the suggestion,
which I did not make ;-),
:D
we'd then give you four hunks (as hunk #1
has been already applied), and even though you have already decided
not to use hunks #2 and #3, you *can* revisit them with "J" or "K",
change your mind and use them if you wanted to. But it is too late
for the hunk #1. It looks utterly inconsistent if you cannot change
your mind on hunk #1 but can on hunks #2 and #3 and it reduces the
usefulness of "you do not have to decide right now and visit other
files before you do so" mode.
Thanks.
Okay yes that would be very inconsistent.
I briefly thought about this.
If a user decides USE on some hunks and goes to the next file, and we
apply the patch, the user comes and decides SKIP on those hunk(s),
can't we "unapply" those hunks using "git apply -R"?
I have not really thought about the complexities but it seems to be
something that might be complex.
I just thought to share to hear your thoughts
Thanks
Abraham