Re: Can we do better than "git checkout/add -p"

Hi Junio,

On Thu, 6 Aug 2026, Junio C Hamano wrote:

> I am doing more "git checkout -p" (selective revert of local changes
> out of the working tree files) these days, as well as "git add -p"
> (selective adding of local changes to the index), and what I often
> wish is to have _both_ as possible options in a single session.
> That is, the local changes in my working tree often fall into three
> categories.  (1) One that is clearly good, (2) one that is good but
> not yet ready, and (3) one that is bogus and should be discarded.
> 
> "git checkout -p" is a way that is very suitable for (3), while "git
> add -p" is a way to deal with (1).  To (2), I say "no" in "git add
> -p", but there is no easy way from "git add -p" to say that the hunk
> is (3).
> 
> My current workaround is not to use "git checkout -p" and instead
> (e)dit an undesirable hunk into a no-op hunk.  This is serviceable,
> but with two caveats:
> 
>  - The underlying 'apply' machinery does not see a truly no-op,
>    context-only hunk.  You'd need to pretend removing an existing
>    line and adding the same line back.
> 
>  - (e)dit applies the edited hunk right away without giving the user
>    a chance to proofread and approve or reedit.

I, too, often find myself in exactly that kind of need. That's why I was
*so* disappointed when
https://lore.kernel.org/git/[email protected]/
was shot down unceremoniously. I still think that would be a good
addition. I even opened https://github.com/gitgitgadget/git/issues/1828
and sketched
https://github.com/git/git/compare/master...dscho:git:add-p-stash-mode to
the same extent.

Maybe it is time to revisit that verdict, and see whether there is really
no way to accept that clearly needed functionality.

Ciao,
Johannes