From: Samuel Abraham Date: Tue, 03 Feb 2026 09:55:38 GMT Subject: Re: [PATCH v2 1/1] Allow reworking with a file after deciding on all its hunks Message-ID: In-Reply-To: On Mon, Feb 2, 2026 at 6:26 PM Junio C Hamano wrote: > > Samuel Abraham writes: > > >> 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