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

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

[Patrick Steinhardt]

On Fri, Aug 07, 2026 at 08:50:39AM -0700, Junio C Hamano 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.

I wonder whether we can take JJ as inspiration. For commands like
jj-split(1) it has the ability to interactively select specific hunks
via `jj split --interactive`, too. But instead of looping through stuff,
it uses a full TUI that:

  - Gives you a list of all files that have changed. On this level you
    can select/deselect the complete file.

  - Also allows you to expand files and then select/deselect individual
    hunks and lines.

I found that model to be quite a bit superior to Git's own interactive
mode.

I've been playing around with the thought of introducing ncurses-based
interfaces into Git. I've been mostly thinking about git-history(1) here
so that you can just move commits around, squash them together, drop
them and so on. But I think fancy stuff like TUIs can also be applied to
other parts of Git, as well, to make things a bit more visual to our
users and, as a consequence, easier to use.

Patrick

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

[Stefan Haller]

On 10.08.26 08:03, Patrick Steinhardt wrote:
> I've been playing around with the thought of introducing ncurses-based
> interfaces into Git. I've been mostly thinking about git-history(1) here
> so that you can just move commits around, squash them together, drop
> them and so on. But I think fancy stuff like TUIs can also be applied to
> other parts of Git, as well, to make things a bit more visual to our
> users and, as a consequence, easier to use.

That sounds a whole lot like lazygit to me [1]; it does all those things
in a rather intuitive way, including Junio's original use case of
selecting a hunk and staging or discarding it.

Is it really worth adding such functionality to core git? I like the
idea of tools specializing on what they do well; core git on providing
the core functionality, GUI tools on presenting it in a UI.

[1] https://github.com/jesseduffield/lazygit

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

[Patrick Steinhardt]

On Mon, Aug 10, 2026 at 09:26:55AM +0200, Stefan Haller wrote:
> On 10.08.26 08:03, Patrick Steinhardt wrote:
> > I've been playing around with the thought of introducing ncurses-based
> > interfaces into Git. I've been mostly thinking about git-history(1) here
> > so that you can just move commits around, squash them together, drop
> > them and so on. But I think fancy stuff like TUIs can also be applied to
> > other parts of Git, as well, to make things a bit more visual to our
> > users and, as a consequence, easier to use.
> 
> That sounds a whole lot like lazygit to me [1]; it does all those things
> in a rather intuitive way, including Junio's original use case of
> selecting a hunk and staging or discarding it.
> 
> Is it really worth adding such functionality to core git? I like the
> idea of tools specializing on what they do well; core git on providing
> the core functionality, GUI tools on presenting it in a UI.
> 
> [1] https://github.com/jesseduffield/lazygit

I think it depends. There are lots of users out there who use core Git,
only, and we often hear complaints from this class of users that Git
makes common workflows way too complex. I certainly think that we should
up our game and try to make such common workflows easier to wield. Tools
like JJ demonstrate that there are a bunch of improvements that we can
do, and many of those aren't even that hard to implement.

So If we see that there are use cases where core Git itself is lacking
and where the consequence is a bad user experience for common workflows
then I think that we should plug that gap in core Git itself.

That being said, I don't think we should get into the business of
building a full UI, as that feels like a can of worms indeed. Adding
something like a user interface around hunk selection certainly feels
like core functionality that I think should be in scope for Git. Whether
a full history-editing user interface should be part of core Git may be
a different question though, as this is getting significantly closer to
a full UI.

Patrick

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

[Junio C Hamano]

Stefan Haller <lists@haller-berlin.de> writes:

> On 10.08.26 08:03, Patrick Steinhardt wrote:
>> I've been playing around with the thought of introducing ncurses-based
>> interfaces into Git. I've been mostly thinking about git-history(1) here
>> so that you can just move commits around, squash them together, drop
>> them and so on. But I think fancy stuff like TUIs can also be applied to
>> other parts of Git, as well, to make things a bit more visual to our
>> users and, as a consequence, easier to use.
>
> That sounds a whole lot like lazygit to me [1]; it does all those things
> in a rather intuitive way, including Junio's original use case of
> selecting a hunk and staging or discarding it.
>
> Is it really worth adding such functionality to core git? I like the
> idea of tools specializing on what they do well; core git on providing
> the core functionality, GUI tools on presenting it in a UI.
>
> [1] https://github.com/jesseduffield/lazygit

My philosophy has always been "do not compete with your customer".

If we add an officially sanctioned XYZ to 'git-core', it would hold
an undue advantage over tools built on 'git-core' that perform the
same task, not because ours is implemented better but merely
because it comes bundled with 'git-core'.  I do not want that.

An exception is when our XYZ is truly of "we wish someone had
written something better that offers functionality like this"
quality, serving as a "usable but perhaps not pretty" demonstration.

Thanks.

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

[Patrick Steinhardt]

On Mon, Aug 10, 2026 at 08:23:00AM -0700, Junio C Hamano wrote:
> Stefan Haller <lists@haller-berlin.de> writes:
> 
> > On 10.08.26 08:03, Patrick Steinhardt wrote:
> >> I've been playing around with the thought of introducing ncurses-based
> >> interfaces into Git. I've been mostly thinking about git-history(1) here
> >> so that you can just move commits around, squash them together, drop
> >> them and so on. But I think fancy stuff like TUIs can also be applied to
> >> other parts of Git, as well, to make things a bit more visual to our
> >> users and, as a consequence, easier to use.
> >
> > That sounds a whole lot like lazygit to me [1]; it does all those things
> > in a rather intuitive way, including Junio's original use case of
> > selecting a hunk and staging or discarding it.
> >
> > Is it really worth adding such functionality to core git? I like the
> > idea of tools specializing on what they do well; core git on providing
> > the core functionality, GUI tools on presenting it in a UI.
> >
> > [1] https://github.com/jesseduffield/lazygit
> 
> My philosophy has always been "do not compete with your customer".
> 
> If we add an officially sanctioned XYZ to 'git-core', it would hold
> an undue advantage over tools built on 'git-core' that perform the
> same task, not because ours is implemented better but merely
> because it comes bundled with 'git-core'.  I do not want that.
> 
> An exception is when our XYZ is truly of "we wish someone had
> written something better that offers functionality like this"
> quality, serving as a "usable but perhaps not pretty" demonstration.

I guess that's fair. As I said in my parallel reply to this message, I
could also see that having something like a git-history(1) UI might be
too much. But I think having a TUI for selecting individual hunks in a
better way compared to `git add -i` and friends might be sensible and
not significantly overlap with other projects.

Patrick