git rebase fast-forward fails with abbreviateCommands

git rebase fast-forward fails with abbreviateCommands

[Jan Alexander Steffens (heftig)]

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

Re: git rebase fast-forward fails with abbreviateCommands

[Alban Gruin]

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

Re: git rebase fast-forward fails with abbreviateCommands

[Elijah Newren]

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

Re: git rebase fast-forward fails with abbreviateCommands

[Jan Alexander Steffens (heftig)]

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.

Re: git rebase fast-forward fails with abbreviateCommands

[Junio C Hamano]

Alban Gruin <alban.gruin@gmail.com> writes:

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

I think the second is the most sensible.  Thanks.

Re: git rebase fast-forward fails with abbreviateCommands

[Alban Gruin]

Hi Elijah,

Le 27/03/2020 à 19:39, Elijah Newren a écrit :

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

Is this even supposed to happen in non-interactive mode?  When I try to
rebase an already up-to-date branch, rebase fails with the message
"Current branch … is up to date."

> Elijah
> 

Cheers,
Alban

[PATCH v1 0/2] rebase --merge: fix fast forwarding when `rebase.abbreviateCommands' is set

[Alban Gruin]

Jan Alexander Steffens reported that when `rebase.abbreviateCommands' is
set, the merge backend fails to fast forward.  This is because the
backend generates a todo list with only a `noop', and since this command
has no abbreviated form, it is replaced by a comment mark.  The
sequencer then interprets it as if there is nothing to do, and fails.

This patch series fixes this issue by teaching the sequencer not to
abbreviate a command if it does not have a short form, and adds a bunch
of regression tests.

This series is based on 9fadedd637 ("Merge branch
'ds/default-pack-use-sparse-to-true'", 2020-03-29).

The tip of this series is tagged as "rebase-dont-abbreviate-v1" at
https://github.com/agrn/git.

Alban Gruin (2):
  sequencer: don't abbreviate a command if it doesn't have a short form
  t3432: test `--merge' with `rebase.abbreviateCommands = true', too

 sequencer.c                    |  9 ++++++---
 t/t3432-rebase-fast-forward.sh | 24 +++++++++++++++++++-----
 2 files changed, 25 insertions(+), 8 deletions(-)

-- 
2.25.0

[PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form

[Alban Gruin]

When the sequencer is requested to abbreviate commands, it will replace
those that does not have a short form (eg. `noop') by a comment mark.
`noop' serves no purpose, except when fast-forwarding (ie. by running
`git rebase').  Removing it will break this command when
`rebase.abbreviateCommands' is set to true.

This changes todo_list_to_strbuf() to check if a command has an actual
short form, and to ignore it if not.

Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
---
 sequencer.c | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/sequencer.c b/sequencer.c
index 6fd2674632..79d0c5cb2e 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -1578,7 +1578,7 @@ static const char *command_to_string(const enum todo_command command)
 
 static char command_to_char(const enum todo_command command)
 {
-	if (command < TODO_COMMENT && todo_command_info[command].c)
+	if (command < TODO_COMMENT)
 		return todo_command_info[command].c;
 	return comment_line_char;
 }
@@ -4963,6 +4963,8 @@ static void todo_list_to_strbuf(struct repository *r, struct todo_list *todo_lis
 		max = num;
 
 	for (item = todo_list->items, i = 0; i < max; i++, item++) {
+		char cmd;
+
 		/* if the item is not a command write it and continue */
 		if (item->command >= TODO_COMMENT) {
 			strbuf_addf(buf, "%.*s\n", item->arg_len,
@@ -4971,8 +4973,9 @@ static void todo_list_to_strbuf(struct repository *r, struct todo_list *todo_lis
 		}
 
 		/* add command to the buffer */
-		if (flags & TODO_LIST_ABBREVIATE_CMDS)
-			strbuf_addch(buf, command_to_char(item->command));
+		cmd = command_to_char(item->command);
+		if (flags & TODO_LIST_ABBREVIATE_CMDS && cmd)
+			strbuf_addch(buf, cmd);
 		else
 			strbuf_addstr(buf, command_to_string(item->command));
 
-- 
2.25.0

[PATCH v1 2/2] t3432: test `--merge' with `rebase.abbreviateCommands = true', too

[Alban Gruin]

When fast forwarding, `git --merge' should act the same whether
`rebase.abbreviateCommands' is set or not, but so far it was not the
case.  This duplicates the tests ensuring that `--merge' works when fast
forwarding to check if it also works with abbreviated commands.

Signed-off-by: Alban Gruin <alban.gruin@gmail.com>
---
 t/t3432-rebase-fast-forward.sh | 24 +++++++++++++++++++-----
 1 file changed, 19 insertions(+), 5 deletions(-)

diff --git a/t/t3432-rebase-fast-forward.sh b/t/t3432-rebase-fast-forward.sh
index 6c9d4a1375..6f0452c0ea 100755
--- a/t/t3432-rebase-fast-forward.sh
+++ b/t/t3432-rebase-fast-forward.sh
@@ -28,10 +28,12 @@ test_rebase_same_head () {
 	shift &&
 	cmp_f="$1" &&
 	shift &&
-	test_rebase_same_head_ $status_n $what_n $cmp_n " --apply" "$*" &&
-	test_rebase_same_head_ $status_f $what_f $cmp_f " --apply --no-ff" "$*"
-	test_rebase_same_head_ $status_n $what_n $cmp_n " --merge" "$*" &&
-	test_rebase_same_head_ $status_f $what_f $cmp_f " --merge --no-ff" "$*"
+	test_rebase_same_head_ $status_n $what_n $cmp_n 0 " --apply" "$*" &&
+	test_rebase_same_head_ $status_f $what_f $cmp_f 0 " --apply --no-ff" "$*"
+	test_rebase_same_head_ $status_n $what_n $cmp_n 0 " --merge" "$*" &&
+	test_rebase_same_head_ $status_f $what_f $cmp_f 0 " --merge --no-ff" "$*"
+	test_rebase_same_head_ $status_n $what_n $cmp_n 1 " --merge" "$*" &&
+	test_rebase_same_head_ $status_f $what_f $cmp_f 1 " --merge --no-ff" "$*"
 }
 
 test_rebase_same_head_ () {
@@ -41,9 +43,21 @@ test_rebase_same_head_ () {
 	shift &&
 	cmp="$1" &&
 	shift &&
+	abbreviate="$1" &&
+	shift &&
 	flag="$1"
 	shift &&
-	test_expect_$status "git rebase$flag $* with $changes is $what with $cmp HEAD" "
+	if test $abbreviate -eq 1
+	then
+		msg="git rebase$flag $* (rebase.abbreviateCommands = true) with $changes is $what with $cmp HEAD"
+	else
+		msg="git rebase$flag $* with $changes is $what with $cmp HEAD"
+	fi &&
+	test_expect_$status "$msg" "
+		if test $abbreviate -eq 1
+		then
+			test_config rebase.abbreviateCommands true
+		fi &&
 		oldhead=\$(git rev-parse HEAD) &&
 		test_when_finished 'git reset --hard \$oldhead' &&
 		cp .git/logs/HEAD expect &&
-- 
2.25.0

Re: [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form

[Junio C Hamano]

Alban Gruin <alban.gruin@gmail.com> writes:

>  static char command_to_char(const enum todo_command command)
>  {
> -	if (command < TODO_COMMENT && todo_command_info[command].c)
> +	if (command < TODO_COMMENT)
>  		return todo_command_info[command].c;
>  	return comment_line_char;
>  }

This is not a new issue, and it may not even be an issue at all, but
it is curious that command_to_string() barfs with "unknown command"
when fed an int outside enum todo_command or TODO_COMMENT iteslf,
while this returns comment_line_char.  Makes a reader wonder if both
of them should be dying the same way.

> @@ -4963,6 +4963,8 @@ static void todo_list_to_strbuf(struct repository *r, struct todo_list *todo_lis
>  		max = num;
>  
>  	for (item = todo_list->items, i = 0; i < max; i++, item++) {
> +		char cmd;
> +
>  		/* if the item is not a command write it and continue */
>  		if (item->command >= TODO_COMMENT) {
>  			strbuf_addf(buf, "%.*s\n", item->arg_len,
> @@ -4971,8 +4973,9 @@ static void todo_list_to_strbuf(struct repository *r, struct todo_list *todo_lis
>  		}
>  
>  		/* add command to the buffer */
> -		if (flags & TODO_LIST_ABBREVIATE_CMDS)
> -			strbuf_addch(buf, command_to_char(item->command));
> +		cmd = command_to_char(item->command);
> +		if (flags & TODO_LIST_ABBREVIATE_CMDS && cmd)

Even though the precedence rule may not require it, for
readability's sake, it would be easier to see the association if
this is written with an extra set of parentheses, i.e.

		if ((flags & TODO_LIST_ABBREVIATE_CMDS) && cmd)

> +			strbuf_addch(buf, cmd);
>  		else
>  			strbuf_addstr(buf, command_to_string(item->command));

The logic is quite clear.  If there is an abbreviation and the user
prefers to see it, we use it, but otherwise we'll give the full
spelling.

We are sure we will never get TODO_COMMENT here in item->command at
this point (the loop would have already continued after adding it to
the buffer), so it does not affect us that command_to_string() would
die.  For that matter, if we made command_to_char() die, just like
command_to_string() would, nobody will get hurt and the resulting
code would become saner.  But obviously it is outside the scope of
this fix (#leftoverbits).

Thanks.

Re: [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form

[Eric Sunshine]

On Mon, Mar 30, 2020 at 8:43 AM Alban Gruin <alban.gruin@gmail.com> wrote:
> When the sequencer is requested to abbreviate commands, it will replace
> those that does not have a short form (eg. `noop') by a comment mark.

s/does/do/

> `noop' serves no purpose, except when fast-forwarding (ie. by running
> `git rebase').  Removing it will break this command when
> `rebase.abbreviateCommands' is set to true.
>
> This changes todo_list_to_strbuf() to check if a command has an actual
> short form, and to ignore it if not.

Perhaps: s/This changes/Change/

> Signed-off-by: Alban Gruin <alban.gruin@gmail.com>