From: phillip.wood123@gmail•com
To: Junio C Hamano <gitster@pobox•com>
Cc: Phillip Wood via GitGitGadget <gitgitgadget@gmail•com>,
git@vger•kernel.org, Phillip Wood <phillip.wood@dunelm•org.uk>
Subject: Re: [PATCH 1/2] add -p: mark split hunks as undecided
Date: Thu, 27 Feb 2025 16:22:50 +0000 [thread overview]
Message-ID: <180271a6-eb0e-4c15-9916-b2ab5760f4ec@gmail.com> (raw)
In-Reply-To: <xmqqikowejmb.fsf@gitster.g>
On 26/02/2025 16:49, Junio C Hamano wrote:
> phillip.wood123@gmail•com writes:
>
>>> "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.
>
> Or directly jump to it with "/go-to-the-one-with-this-string"?
Oh, I'd forgotten '/' searches all the hunks rather than just the
undecided ones.
>> 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.
>
> Hmph, so there is an obvious alternative "fix" to the inconsistency,
> i.e., after splitting, move to the first unselected hunk?
We could do that but I think it would be even more confusing than the
current behavior as it would make it harder to change the state of the
mini-hunks. At least with the current behavior one can use 'J' to move
through them immediately after splitting the original hunk. If we move
to the next undecided hunk one has to know where the newly-created
mini-hunks are relative to that.
>> 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.
>
> And the alternative may resolve the inconsistency and make it less
> work for the users? I dunno.
I'm not sure either. I dislike the way it works at the moment and find
it confusing but if there are a lot of people relying on it then I'd be
reluctant to change it. Unfortunately we don't have any way to know if
anyone is relying on the current behavior without changing it and seeing
if anyone complains. Given it is a bit of a corner case I'm not sure
whether it is worth spending much more time on it.
> This is totally orthogonal to this "split" issue and outside the
> scope of this topic, but one thing that I do not like the design of
> "add -p", which most likely was inherited from the very initial
> iteration before it was rewritten in C, is that we never ask
> reconfirmation once all the hunks got decided. With 3 hunks, after
> choosing hunk #1 by mistake, I can still go back and correct the
> mistake even if I noticed the mistake after making decision on the
> hunk #2 (thanks to the fact that hunk #3 hasn't been decided), but
> if the hunk #3 is missing, going back and correcting #1 becomes
> impossible as the program exits immediatly after deciding on #2.
> But I guess this depends not just on the user but on occasion.
> After all, re-running "reset/add -p" after such a mistake is not so
> huge a deal anyway.
I can see the problem and asking for conformation before quitting would
have been nice if we'd done it from the start. I'm not sure it is worth
the disruption of changing it when one can re-run "reset/add -p" quite
easily though. I guess we could add an opt-in cofing that eventually
becomes the default.
While we're talking about tangential issues it would be nice if when a
user revisited a hunk we told them its current state. At the moment
there is no way to tell if a hunk has been selected or not. Related to
that the help for 'J' and 'K' talk about leaving the current hunk
undecided when what they actually do is leave the current state unchanged.
Best Wishes
Phillip
next prev parent reply other threads:[~2025-02-27 16:22 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-21 14:57 [PATCH 0/2] add -p: a couple of hunk splitting fixes Phillip Wood via GitGitGadget
2025-02-21 14:57 ` [PATCH 1/2] add -p: mark split hunks as undecided Phillip Wood via GitGitGadget
2025-02-21 19:52 ` Justin Tobler
2025-02-21 21:31 ` Junio C Hamano
2025-02-26 14:40 ` phillip.wood123
2025-02-26 16:49 ` Junio C Hamano
2025-02-27 16:22 ` phillip.wood123 [this message]
2025-02-27 18:36 ` Junio C Hamano
2025-02-28 16:19 ` Phillip Wood
2025-02-28 17:06 ` Junio C Hamano
2025-03-04 10:25 ` Phillip Wood
2025-02-21 14:57 ` [PATCH 2/2] add-patch: update hunk splitability after editing Phillip Wood via GitGitGadget
2025-02-21 20:29 ` Justin Tobler
2025-02-21 21:42 ` Junio C Hamano
2025-09-15 15:29 ` [PATCH v2 0/2] add -p: a couple of hunk splitting fixes Phillip Wood via GitGitGadget
2025-09-15 15:29 ` [PATCH v2 1/2] add -p: mark split hunks as undecided Phillip Wood via GitGitGadget
2025-09-15 17:44 ` Junio C Hamano
2025-09-16 9:36 ` Phillip Wood
2025-09-16 16:03 ` Junio C Hamano
2025-09-15 15:29 ` [PATCH v2 2/2] add-patch: update hunk splitability after editing Phillip Wood via GitGitGadget
2025-09-25 15:10 ` [PATCH v3 0/2] add -p: a couple of hunk splitting fixes Phillip Wood via GitGitGadget
2025-09-25 15:10 ` [PATCH v3 1/2] add -p: mark split hunks as undecided Phillip Wood via GitGitGadget
2025-09-25 18:21 ` Junio C Hamano
2025-09-26 10:12 ` Phillip Wood
2025-09-26 17:37 ` Junio C Hamano
2025-10-08 13:51 ` Phillip Wood
2025-09-25 15:10 ` [PATCH v3 2/2] add-patch: update hunk splitability after editing Phillip Wood via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=180271a6-eb0e-4c15-9916-b2ab5760f4ec@gmail.com \
--to=phillip.wood123@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=phillip.wood@dunelm$(echo .)org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox