From: Junio C Hamano <gitster@pobox.com>
To: "Phillip Wood via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH 1/2] add -p: mark split hunks as undecided
Date: Fri, 21 Feb 2025 13:31:23 -0800 [thread overview]
Message-ID: <xmqq34g79e8k.fsf@gitster.g> (raw)
In-Reply-To: <43a0592a462cf68bcfdc54373da2319431c3c1ca.1740149837.git.gitgitgadget@gmail.com> (Phillip Wood via GitGitGadget's message of "Fri, 21 Feb 2025 14:57:16 +0000")
"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.
So, I dunno.
next prev parent reply other threads:[~2025-02-21 21:31 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 [this message]
2025-02-26 14:40 ` phillip.wood123
2025-02-26 16:49 ` Junio C Hamano
2025-02-27 16:22 ` phillip.wood123
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=xmqq34g79e8k.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).