Re: [PATCH 3/3] rebase: new convenient option to edit a single commit

[Junio C Hamano <gitster@pobox.com>]

Michael Haggerty <mhagger@alum.mit.edu> writes:

> ...  All of the following seem to make sense:
>
>     git rebase --edit COMMIT
>
>         A long-form for the -e option we have been talking about.
>         It is unfortunately that this spelling sounds like the
>         "--edit" option on "git commit --edit" and "git merge --edit",
>         so people might use it when they really mean
>         "git rebase --reword COMMIT".

I agree, so the "--edit" does *not* make sense as it invites confusion.

>     git rebase --reword COMMIT

Yes, that would make sense.

>     git rebase --fixup COMMIT
>     git rebase --squash COMMIT

I am not sure about these.  What does it even mean to "--fixup" (or
"--squash" for that matter) a single commit without specifying what
it is squashed into?  Or are you assuming that all of these is only
to affect pre-populated rebase-i insn sheet that is to be further
edited before the actual rebasing starts?  I somehow had an impression
that the reason to have these new options is to skip the editing of
the insn sheet in the editor altogether.

>     git rebase --kill COMMIT

This _does_ make sense under my assumption: "remove this commit from
the insn-sheet and go ahead with it, without bothering me to edit
the insn-sheet further".

> I'm quite confident that I would use all of these commands.

If "--kill" takes only one, I would probably do "rebase --onto"
without bothering with "-i" at all, but if it lets me drop multiple
non-consecutive commits, by accepting more than one "--kill", I see
how I would be using it myself.  I can see how "--reword"/"--amend"
would be useful even when dealing with only a single commit.

I do not know about --fixup/--squash though.