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

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

> > 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.

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/[email protected]/

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