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

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