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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 4, 2014, 18:37 UTC
Message-ID: <xmqqeh2hlsiu.fsf@gitster.dls.corp.google.com>
In-Reply-To: <53159601.8020702@alum.mit.edu>

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

Show 9 quoted lines

> ...  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.