Jeff King wrote:
> > [Let's just forget about the original patch at the top of the thread;
> > in retrospect, it _is_ clunky, and the UI didn't get any replies in
> > favour.]
> 
> It seems like Junio isn't all that keen on the raw patch-editing
> interface. And even if we do like it, I think there is still room for a
> less error-prone but more restrictive feature that mere mortals can use.
> So maybe there is a better interface yet.

Maybe git gui could do a sort of "toggle the lines I click" interface.
But I don't know anything about Tk, or Tcl, or git gui :-(

> What about 'S' to do a "line split"; that is, take the current hunk, and
> anywhere there are adjacent changed lines, split them into their own
> hunks.
[...]
> and then we proceed as usual, staging or not each split hunk. It would
> be clunky to separate one or two lines from a huge chunk (since you
> would inadvertently split the huge chunk and have to stage each
> individually). But in many cases you can split into smaller hunks first
> with 's'.

Now I'm slightly confused.

Doing it that way would be almost like my original patch

  http://www.spinics.net/lists/git/msg66971.html

minus the numeric prefixes -- meaning that you have to say y/n to
_every_ line in the patch, at least until all remaining hunks are the
same and you can answer the rest with a/d.

Except that it wouldn't work anyway, because git-apply refuses hunks
that have no context (even if just on one end).  Unless given
--unidiff-zero, but that apparently was one of the points of refusal
in the thread Dscho linked earlier:

  http://thread.gmane.org/gmane.comp.version-control.git/67854/focus=68127

Granted, we could insert extra context and/or make sure the mentioned
data loss can never happen (it's probably prevented by 'add -p's own
recounting before the final apply), but the first would make the UI
even more confusing and the second is potentially dangerous.

- Thomas

-- 
Thomas Rast
trast@student.ethz.ch