On Mon, Jun 09, 2008 at 07:46:22AM +0200, Johan Herland wrote:
> 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.
> ("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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
