Michael Haggerty <mhag...@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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html