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

On Wed, Aug 12, 2026 at 10:40:08AM +0200, Johannes Schindelin wrote:

quoted

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/20260325075055.354709-1-luizedc1@gmail.com/ (local)
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.

Thanks for digging up that link. After reading Junio's message that
started this thread, I _thought_ we had discussed this a dozen times
already, but after searching the archive could only come up with this
thread:

  https://lore.kernel.org/git/20161102223705.qycdo3j2bvndi7ev@sigill.intra.peff.net/ (local)

But the one you linked is another example, and nicely links back
recursively to at least two other instances. ;)

I see I am quoted in one of them as "it's a little weird for add -p to
change the working tree", but I want to make clear that I _don't_ oppose
a feature like this. I think it would be super useful. We may find a way
to avoid that "weird" property (e.g., by putting the "combined"
stash/add mode under a different command's "-p"), or we may just accept
it.

-Peff