Re: git rebase fast-forward fails with abbreviateCommands

["Jan Alexander Steffens (heftig)" <jan.steffens@gmail.com>]

On Fri, 2020-03-27 at 11:39 -0700, Elijah Newren wrote:
> 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?

Changing just the message and return code wouldn't be enough, as the
empty todo results in the rebase being aborted without fast-forwarding
the branch.