Re: git rebase -f --autosquash

Andy Kitchen [off-list ref] writes:

1a)

$ git rebase -f --autosquash <base>
is made to be effectively equivalent to:
$ EDITOR=: git rebase -i --autosquash <base>

I am not sure how you do the above without breaking the existing users and
other people's use cases, given that giving --force option to rebase has
totally different meaning from the above (i.e. "do not refuse to rebase
even though the current branch is up to date with respect to <base>").
Such an option overloading, especially for an option "force", feels adding
confusion without much merit---it is unclear what kind of "forcing" is it
calling for.

1b)

$ git rebase --autosquash <base>
(i.e. -f is implicit) is made to be effectively equivalent to:
$ EDITOR=: git rebase -i --autosquash <base>

I do not think this would work.  

The --autosquash option is merely a way to help reordering by moving the
"fixup!" commits in the history around without manual action You may have
commits created with "fix" but _other_ commits in the history that you
want to manually reorder in the insn sheet.

3) A new command is created, for example one of:

$ git fix
$ git squash
$ git autosquash

All of these names are so broad and generic---I am not sure if any of them
will "click" with your single narrow use case, which as far as I can see
is "I want rebase with --autosquash but I am not going to do any other
editing."  None of the above three words hints the new command is about
rebasing.

Even though I find the "I want rebase with --autosquash but I am not going
to do any other editing." is a workflow element that often appears in the
real life, I do not think it deserves its own command that is separate
from "rebase".  It is merely a slightly different way to drive "rebase",
after all.

And that "I want rebase with --autosquash but I am not going to do any
other editing" is where my suggestion to use "--no-edit" comes from.