Re: git rebase -f --autosquash

On Sun, May 27, 2012 at 2:44 AM, Junio C Hamano [off-list ref] wrote:

Andy Kitchen [off-list ref] writes:

quoted

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.

quoted

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.

quoted

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.

Your suggestion is not that he use "rebase --autosquash --no-edit" but
that he use "rebase --autosquash --interactive --no-edit".  The last
two options appear to be opposites from the outsider's perspective and
would seem to be superfluous.  I understand from the code perspective
that "rebase" and "rebase --interactive" are in separate
implementations; but from this user's perspective, they are the same
with one distinction; the former performs an automatic sequence of
commit actions, while the latter shows the sequence first and allows
me to edit it.  So the command "git rebase --interactive --no-edit"
reads to me like "git rebase --ask-me-how --noask-me-how", which is
nonsensical, at best.

The only reason Andy would have to add --no-edit to his command is
because the --autosquash option is, inexplicably, only valid in
--interactive mode.  This seems pointless from this user's
perspective.  Why does the --autosquash option also need the
"--ask-me-how" option?  If I don't need the --ask-me-how action, I
should simply leave it off.  I should not need to also add
"--no-ask-me-how".

That would look nonsensical.

Maybe it seems explicable to you because "squash" is a todo-list
command which is only valid in --interactive.  But this, too, is a
detail best left buried in the implementation and not exposed to the
CLI, imho.

quoted

1b)

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

This would be my preference, except that it is the "--interactive
--no-edit" which is made implicit when --autosquash is used without
"--interactive".  The fact that these two options are implicit should
be hidden from the user and not required of him.  That both are
required seems to me to be an embarrassing, historical implementation
detail.

Phil