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

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

From
Pphillip.wood123@gmail.com <phillip.wood123@gmail.com>
Date
Feb 26, 2025, 14:40 UTC
Message-ID
<618d4a61-7480-46b7-8563-221264290ed1@gmail.com>
In-Reply-To
<xmqq34g79e8k.fsf@gitster.g>
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:
Show 40 quoted lines
> "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
>> 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. 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.
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 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.