From: Junio C Hamano Date: Tue, 04 Mar 2014 18:37:13 GMT Subject: Re: [PATCH 3/3] rebase: new convenient option to edit a single commit Message-ID: In-Reply-To: <53159601.8020702@alum.mit.edu> Michael Haggerty 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.