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

[Patrick Steinhardt <ps@pks.im>]

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