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

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