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

Re: [PATCH v2 1/2] add -p: mark split hunks as undecided

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 15, 2025, 17:44 UTC
Message-ID
<xmqqbjnbhapy.fsf@gitster.g>
In-Reply-To
<3e2ec7b37f1935c5b091fc4b47b6209beb384d3a.1757950144.git.gitgitgadget@gmail.com>
"Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 20 quoted lines
> From: Phillip Wood <phillip.wood@dunelm.org.uk>
>
> When a hunk is split, each of the new hunks inherits whether it is
> selected or not from the original hunk. If a selected hunk is split
> all of the new hunks are marked as "selected" and the user is only
> prompted with the first of the split hunks. The user is not asked
> whether or not they wish to select the rest of the new hunks. This
> means that if they wish to deselect any of the new hunks apart from
> the first one they have to navigate back to the hunk they want to
> deselect before they can deselect it. This is unfortunate as the user
> is presumably splitting the original hunk because they only want to
> select some sub-set of it.
>
> Instead mark all the new hunks as "undecided" so that the user is
> prompted whether they wish to select each one in turn. In the case
> where the user only wants to change the selection of the first of
> the split hunks they will now have to do more work re-selecting the
> remaining split hunks. However, changing the selection of any of the
> other newly created hunks is now much simpler as the user no-longer has
> to navigate back to them in order to change their selected state.
That is great, but ...
> Due
> to concerns that users may be relying on the current behaviour [1]
> this change is guarded by WITH_BREAKING_CHANGES.

... this does not really sound like a good candidate for "before version X we used to do this, but after X we no longer do so".

Unless it is a mere bugfix, in which case such a change does not deserve a huge-version-bump switchover like this.

On the other hand, assuming it is not a bugfix but introducing a different behaviour, where both the original and the new ones are useful depending on the situation, wouldn't it be better to give users choices at runtime instead, with a configuration variable at least, but possibly with a interactive command to choose which behaviour is used on demand?

Previous: Phillip Wood via GitGitGadgetNext: Phillip Wood
Message 17 of 27 in “add -p: a couple of hunk splitting fixes”
  1. 0/2 add -p: a couple of hunk splitting fixesPhillip Wood via GitGitGadget, Feb 21, 2025
  2. 1/2 add -p: mark split hunks as undecidedPhillip Wood via GitGitGadget, Feb 21, 2025
  3. Justin ToblerFeb 21, 2025
  4. Junio C HamanoFeb 21, 2025
  5. phillip.wood123@gmail.comFeb 26, 2025
  6. Junio C HamanoFeb 26, 2025
  7. phillip.wood123@gmail.comFeb 27, 2025
  8. Junio C HamanoFeb 27, 2025
  9. Phillip WoodFeb 28, 2025
  10. Junio C HamanoFeb 28, 2025
  11. Phillip WoodMar 4, 2025
  12. 2/2 add-patch: update hunk splitability after editingPhillip Wood via GitGitGadget, Feb 21, 2025
  13. Justin ToblerFeb 21, 2025
  14. Junio C HamanoFeb 21, 2025
  15. 0/2 add -p: a couple of hunk splitting fixesPhillip Wood via GitGitGadget, Sep 15, 2025
  16. 1/2 add -p: mark split hunks as undecidedPhillip Wood via GitGitGadget, Sep 15, 2025
  17. Junio C HamanoSep 15, 2025
  18. Phillip WoodSep 16, 2025
  19. Junio C HamanoSep 16, 2025
  20. 2/2 add-patch: update hunk splitability after editingPhillip Wood via GitGitGadget, Sep 15, 2025
  21. 0/2 add -p: a couple of hunk splitting fixesPhillip Wood via GitGitGadget, Sep 25, 2025
  22. 1/2 add -p: mark split hunks as undecidedPhillip Wood via GitGitGadget, Sep 25, 2025
  23. Junio C HamanoSep 25, 2025
  24. Phillip WoodSep 26, 2025
  25. Junio C HamanoSep 26, 2025
  26. Phillip WoodOct 8, 2025
  27. 2/2 add-patch: update hunk splitability after editingPhillip Wood via GitGitGadget, Sep 25, 2025

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.