On Mon, Jun 09, 2008 at 07:46:22AM +0200, Johan Herland wrote:

quoted text
> Is there a good reason against having *both*?
> 
> AFAICS, there's nothing stopping us from having both a "-e"-option to 
> git-add, and an "e"-command inside git-add--interactive.

I agree (and I tried to make that point in an earlier mail).

And I was hoping the right way to do it was to simply build the
interactive "e" command on top of Johannes' git-apply work. But I don't
think that quite makes sense. His work is about fixing up the hunk
header as we apply the patch, but a working "e" command in the hunk
selection should probably not actually apply, but simply split into two
hunks for the loop.

quoted text
> ("git-add -e" would open the entire diff in an editor, as would "e" from the 
> *main* menu of git-add--interactive. However, "e" from the *single hunk* 
> menu would of course open only that single hunk within the editor. We could 
> even have an "E" command to open all remaining/undecided hunks in an 
> editor.)

I agree with all of this, though I think the big question is what
happens to the edited portion. In the interactive command, I think it
becomes a new hunk that can be staged or not. In "git add -e" it makes
sense to simply stage the result.

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html