On Thu, Jun 12, 2008 at 08:55:24AM +0200, Thomas Rast wrote: > > > +# If the patch applies cleanly, the hunk will immediately be marked > > > +# for staging as if you had answered 'y'. (However, if you remove > > > +# everything, nothing happens.) Otherwise, you will be asked to edit > > > +# again. > [...] > I wanted to make the same special case that 'recount -i' has: Deleting > everything does not "do nothing", but actually aborts the edit. So in > rebase, deleting everything will not rebase anything (instead of > rebasing "no patches" onto wherever you said). Along the same lines, > in the above patch deleting everything does not patch "no changes", > but aborts editing the hunk and leaves it unchanged. > > Do you think that behaviour confuses users? Ah, OK. That makes sense. I think it could be worded more explicitly, though. Maybe: If the patch applies cleanly, the edited hunk will immediately be marked for staging. If it does not apply cleanly, you will be given an opportunity to edit again. If all lines of the hunk are removed, then the edit is aborted and the hunk is left unchanged. > Feeding it the single hunk would be enough, but doing it this way > ensures that the edited hunk cannot step on another hunk's toes, > i.e. produce a conflict that may prevent us from applying the patch at > the end of the hunk selection loop. > > It's fairly unlikely of course, because the user would deliberately > have to extend the hunk beyond its current borders by adding extra > context from the original file. Right, but you may get false positives if a later conflicting hunk is not staged. Though as you say, I think it is unlikely in either case. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
