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@xxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
