Re: git rebase fast-forward fails with abbreviateCommands

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux