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

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

[Junio C Hamano]

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.

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

[Christian Couder]

On Fri, Aug 7, 2026 at 6:02 AM Junio C Hamano <gitster@pobox.com> 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.

What if there is a hunk you want to squash to a previous commit like
HEAD~2 or to a new commit in a separate branch?

I think that if we add a new way to handle hunks, we should consider
more cases than just reverting, keeping or indexing. We could perhaps
take advantage of recent developments in `git history` to implement
the additional cases.

On the other hand, it seems to me that GitButler's `but rub` command
could do a lot of things like that, but it looks like they recently
replaced and split that command into more explicit, intent-based
commands (see https://github.com/gitbutlerapp/gitbutler/releases).

So I guess the main issue in designing such a feature is to make it do
many things, but not too many.

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

[D. Ben Knoble]

On Fri, Aug 7, 2026 at 12:03 AM Junio C Hamano <gitster@pobox.com> 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).

Not a core Git solution, but the interface provided by Fugitive [1]
(inspired by Magit) makes it easy to browse all hunks, with options to
(e.g.) stage, unstage, or revert.

(The revert command even shows how to bring back the reverted content,
in case you made a mistake.)

It's a bit hard to explain how this works over email. There's an old
video [2] which doesn't reflect many newer enhancements to Fugitive
(e.g., you no longer need to open a file to diff it; you can toggle
the "git diff" or "git diff --cached" view from within the status
buffer---from there, all the staging/unstaging/discard maps work on
individual hunks or ranges of lines), but still shows the general
idea.

[1]: https://github.com/tpope/vim-fugitive
[2]: http://vimcasts.org/episodes/fugitive-vim-working-with-the-git-index/

I raise this as the kind of interface we could learn from: emulating
it might be a bit heavier (a full TUI?), but is certainly more
convenient to use than the prompt-loop over hunks.

Best,
-- 
D. Ben Knoble

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

[Junio C Hamano]

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

> I raise this as the kind of interface we could learn from: emulating
> it might be a bit heavier (a full TUI?), but is certainly more
> convenient to use than the prompt-loop over hunks.

Yes, the 'one hunk at a time' model was easy to implement and start
using, but its limitations are apparent.  Users want to be able to
jump around, starting in the middle and returning to the top later,
for example.

It is more or less orthogonal to the reason I started this
discussion, though, which is that limiting the direction in which
modifications flow restricts the workflow, burdens the user, and
makes the process error-prone.

When I see a hunk, I can immediately tell if it is one of three
kinds (i.e., those we want to add, those we want to leave in the
working tree, and those we want to discard from the working tree).
But with 'git add -p' (especially with the original version of the
feature, before the 'e' (edit) command was introduced), the third
kind must be treated the same way as the second.  Then, after I am
done with 'git add -p', I must go through the remaining hunks, sift
them into two categories (those we want to keep in the working tree
and those we want to discard), and run 'git checkout -p' to deal
with the latter.

We should be able to improve this workflow without deviating from
the 'one hunk at a time' model.

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

[D. Ben Knoble]

On Fri, Aug 7, 2026 at 11:50 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> "D. Ben Knoble" <ben.knoble@gmail.com> writes:
>
> > I raise this as the kind of interface we could learn from: emulating
> > it might be a bit heavier (a full TUI?), but is certainly more
> > convenient to use than the prompt-loop over hunks.
>
> Yes, the 'one hunk at a time' model was easy to implement and start
> using, but its limitations are apparent.  Users want to be able to
> jump around, starting in the middle and returning to the top later,
> for example.
>
> It is more or less orthogonal to the reason I started this
> discussion, though, which is that limiting the direction in which
> modifications flow restricts the workflow, burdens the user, and
> makes the process error-prone.
>
> When I see a hunk, I can immediately tell if it is one of three
> kinds (i.e., those we want to add, those we want to leave in the
> working tree, and those we want to discard from the working tree).
> But with 'git add -p' (especially with the original version of the
> feature, before the 'e' (edit) command was introduced), the third
> kind must be treated the same way as the second.  Then, after I am
> done with 'git add -p', I must go through the remaining hunks, sift
> them into two categories (those we want to keep in the working tree
> and those we want to discard), and run 'git checkout -p' to deal
> with the latter.
>
> We should be able to improve this workflow without deviating from
> the 'one hunk at a time' model.

Perhaps I emphasized the wrong attributes; what initially brought
Fugitive to mind is the fact that one set of commands move hunks
between staged, unstaged, and reverted.

Whether that's in a more complex interface or not, that seemed like
the thrust of what you were after.

-- 
D. Ben Knoble

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

[Junio C Hamano]

"D. Ben Knoble" <ben.knoble@gmail.com> writes:

>> We should be able to improve this workflow without deviating from
>> the 'one hunk at a time' model.
> ...
> Whether that's in a more complex interface or not, that seemed like
> the thrust of what you were after.

It seems to me that we are saying the same thing ;-).