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

On Fri, Aug 7, 2026 at 11:50 AM Junio C Hamano <[email protected]> wrote:
>
> "D. Ben Knoble" <[email protected]> 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