Re: git rebase fast-forward fails with abbreviateCommands

From: Alban Gruin <alban.gruin@gmail.com>
Date: Mar 27, 2020, 15:46 UTC
Message-ID: <a3cc46ca-824d-8cab-e333-83f51a7824ca@gmail.com>
In-Reply-To: <9b4bc756764d87c9f34c11e6ec2fc6482f531805.camel@gmail.com>

Hi Jan,

+cc Johannes, Elijah, and Phillip.

Le 27/03/2020 à 12:44, Jan Alexander Steffens (heftig) a écrit :

Show 15 quoted lines

> 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.

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.

Thank you again for reporting this.

Cheers, Alban