git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 1/1] Allow reworking with a file after deciding on all its hunks

From
Samuel Abraham <abrahamadekunle50@gmail.com>
Date
Feb 3, 2026, 09:55 UTC
Message-ID
<CADYq+faasM8h0FJjop4GJeo_6fw-=_VXRZeqYURDbQFuR0CK1A@mail.gmail.com>
In-Reply-To
<xmqqzf5rys3f.fsf@gitster.g>
On Mon, Feb 2, 2026 at 6:26 PM Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
>
> Samuel Abraham <abrahamadekunle50@gmail.com> 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.
Show 10 quoted lines
>
> 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
Show 10 quoted lines
> 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

Previous: Junio C HamanoNext: Junio C Hamano
Message 15 of 54 in “add-patch: Allow reworking with a file after deciding on its hunks”
  1. 0/1 add-patch: Allow reworking with a file after deciding on its hunksAbraham Samuel Adekunle, Jan 23, 2026
  2. 1/1 add-patch: Allow reworking with a file after deciding on all its hunksAbraham Samuel Adekunle, Jan 23, 2026
  3. Junio C HamanoJan 23, 2026
  4. Samuel AbrahamJan 23, 2026
  5. 0/1 Allow reworking with a file when making hunk decisionsAbraham Samuel Adekunle, Jan 27, 2026
  6. 1/1 Allow reworking with a file after deciding on all its hunksAbraham Samuel Adekunle, Jan 27, 2026
  7. Junio C HamanoJan 27, 2026
  8. Samuel AbrahamJan 28, 2026
  9. Samuel AbrahamJan 30, 2026
  10. Junio C HamanoJan 30, 2026
  11. Samuel AbrahamJan 30, 2026
  12. Junio C HamanoJan 31, 2026
  13. Samuel AbrahamFeb 2, 2026
  14. Junio C HamanoFeb 2, 2026
  15. Samuel AbrahamFeb 3, 2026
  16. Junio C HamanoJan 27, 2026
  17. Samuel AbrahamJan 28, 2026
  18. 0/3 introduce new option `rework-with-file`Abraham Samuel Adekunle, Feb 6, 2026
  19. 1/3 interactive -p: add new `--rework-with-file` flag to interactive machineryAbraham Samuel Adekunle, Feb 6, 2026
  20. Junio C HamanoFeb 6, 2026
  21. Samuel AbrahamFeb 6, 2026
  22. 2/3 add-patch: Allow interfile navigation when selecting hunksAbraham Samuel Adekunle, Feb 6, 2026
  23. Junio C HamanoFeb 6, 2026
  24. Samuel AbrahamFeb 6, 2026
  25. Junio C HamanoFeb 6, 2026
  26. Samuel AbrahamFeb 6, 2026
  27. Junio C HamanoFeb 6, 2026
  28. Samuel AbrahamFeb 6, 2026
  29. Samuel AbrahamFeb 12, 2026
  30. Junio C HamanoFeb 12, 2026
  31. Samuel AbrahamFeb 12, 2026
  32. Junio C HamanoFeb 12, 2026
  33. Samuel AbrahamFeb 12, 2026
  34. 3/3 add-patch: Allow proper 'git apply' when using the --rework-with-file flagAbraham Samuel Adekunle, Feb 6, 2026
  35. Junio C HamanoFeb 6, 2026
  36. Samuel AbrahamFeb 6, 2026
  37. Junio C HamanoFeb 6, 2026
  38. Samuel AbrahamFeb 6, 2026
  39. 0/4 introduce new option `--auto-advance`Abraham Samuel Adekunle, Feb 13, 2026
  40. 1/4 interactive -p: add new `--auto-advance` flagAbraham Samuel Adekunle, Feb 13, 2026
  41. Junio C HamanoFeb 13, 2026
  42. Samuel AbrahamFeb 14, 2026
  43. 2/4 add-patch: modify patch_update_file() signatureAbraham Samuel Adekunle, Feb 13, 2026
  44. Junio C HamanoFeb 13, 2026
  45. Samuel AbrahamFeb 14, 2026
  46. 3/4 add-patch: allow all-or-none application of patchesAbraham Samuel Adekunle, Feb 13, 2026
  47. 4/4 add-patch: allow interfile navigation when selecting hunksAbraham Samuel Adekunle, Feb 13, 2026
  48. 0/4 introduce new option `--auto-advance`Abraham Samuel Adekunle, Feb 14, 2026
  49. 1/4 interactive -p: add new `--auto-advance` flagAbraham Samuel Adekunle, Feb 14, 2026
  50. 2/4 add-patch: modify patch_update_file() signatureAbraham Samuel Adekunle, Feb 14, 2026
  51. 3/4 add-patch: allow all-or-none application of patchesAbraham Samuel Adekunle, Feb 14, 2026
  52. 4/4 add-patch: allow interfile navigation when selecting hunksAbraham Samuel Adekunle, Feb 14, 2026
  53. Junio C HamanoFeb 20, 2026
  54. Samuel AbrahamFeb 21, 2026

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.