On Monday 09 June 2008, Jeff King wrote:
> 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.
Yeah, the two approaches don't merge easily...
> 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.
By "split into two hunks", you mean splitting the original "index ->
worktree" hunk (#0) into one hunk that represents "index -> edited" (#1),
and another hunk that represents "edited -> worktree" (#2)?
>From a technical POV this might make sense, but AFAICS, users would always
want to answer 'y' to #1, and 'n' to #2 (see [1]), so from a user POV,
git-add--interactive should simply stage #1, and drop #2.
(Side note: AFAIR, some of the original rationale for this feature was to
provide a more fine-grained split than 's'. Looking at the problem from
this POV: What is the reason for splitting a hunk in the first place? It
must be because one part of the hunk should be staged while leaving the
other unstaged. With 's', it just splits, and lets the user select which
parts of the hunk to stage, using 'y'/'n'. But 'e' introduces a much more
powerful notion of letting user split AND select in ONE operation (i.e. the
editor). Therefore, when the user has already selected which parts of the
hunk to stage (#1), it is not necessary to re-ask the user whether or not
#1 should be staged (and certainly not #2).
> > ("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.
Sounds acceptable to me (although I would also be ok with automatically
staging the edited portion in the interactive command).
Have fun! :)
...Johan
[1]: AIUI #1 represents the hunk that the user want to stage at this moment.
Conversely, #2 represents the changes that the user is NOT interested in
staging at this point. Therefore, the only answers that make sense is 'y'
(i.e. "stage this hunk") for #1 and 'n' (i.e. "do not stage this hunk") for
#2. The only problem with this is if the user screwed up the hunk edit and
wants to revert to the original hunk (#0). I don't know if this is worth
supporting.
--
Johan Herland, <johan@xxxxxxxxxxx>
www.herland.net
--
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
