Re: git rebase fast-forward fails with abbreviateCommands

[Elijah Newren <newren@gmail.com>]

Hi Alban,

On Fri, Mar 27, 2020 at 8:46 AM Alban Gruin <alban.gruin@gmail.com> wrote:
>
> Hi Jan,
>
> +cc Johannes, Elijah, and Phillip.
>
> Le 27/03/2020 à 12:44, Jan Alexander Steffens (heftig) a écrit :
> > Hi,
> >
> > Since 2.26.0 a simple "git rebase" fails to fast-forward a
> > branch, reporting "error: nothing to do."
> >
> > It started to work again after removing my gitconfig. I've
> > reduced it to the following:
> >
> >     git init foo; cd foo
> >     git commit --allow-empty -m foo
> >     git commit --allow-empty -m bar
> >     git checkout -tb foo
> >     git reset HEAD~
> >     git -c rebase.abbreviateCommands=true rebase
> >
>
> Thank you for reporting this bug.
>
> Since git 2.26, the default rebase backend switched from "am" to
> "merge".  So, by default, a todo list is created, even if you can't see it.
>
> In this case, the todo list contains only a `noop', but this command has
> no short form, and is abbreviated with a comment mark.  As there is no
> more commands in the list, the backend will fail with the error "nothing
> to do".
>
> Three approach to fix this:
>
>  1) add an abbreviation to `noop';  this is the simplest fix, and "n" is
> not taken.
>  2) if a command has no short form, do not abbreviate it;  this is
> trivial to do, and should not break anything.

Both sound reasonable to me.

> A third approach would be to change the meaning of an empty buffer, but
> this would break some tests (at least t3404.3) and cause more confusion
> for users than necessary.

Well, "error: nothing to do" probably makes sense if the user
specifies a list of empty commands or sees a list of empty commands
and agrees to pass these to the backend.  But I'm not sure that
message makes sense for implicitly interactive runs as opposed to
explicitly interactive ones.  Perhaps we could change the message to
just be "Already up to date" if the buffer is empty and the run is not
explicitly interactive?


Elijah