Michael Haggerty <mhagger@xxxxxxxxxxxx> 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. -- 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