* git rebase fast-forward fails with abbreviateCommands
@ 2020-03-27 11:44 Jan Alexander Steffens (heftig)
2020-03-27 15:46 ` Alban Gruin
2020-03-30 12:42 ` [PATCH v1 0/2] rebase --merge: fix fast forwarding when `rebase.abbreviateCommands' is set Alban Gruin
0 siblings, 2 replies; 11+ messages in thread
From: Jan Alexander Steffens (heftig) @ 2020-03-27 11:44 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: git rebase fast-forward fails with abbreviateCommands 2020-03-27 11:44 git rebase fast-forward fails with abbreviateCommands Jan Alexander Steffens (heftig) @ 2020-03-27 15:46 ` Alban Gruin 2020-03-27 18:39 ` Elijah Newren 2020-03-27 21:33 ` Junio C Hamano 2020-03-30 12:42 ` [PATCH v1 0/2] rebase --merge: fix fast forwarding when `rebase.abbreviateCommands' is set Alban Gruin 1 sibling, 2 replies; 11+ messages in thread From: Alban Gruin @ 2020-03-27 15:46 UTC (permalink / raw) To: Jan Alexander Steffens (heftig), git Cc: Johannes Schindelin, Elijah Newren, Phillip Wood 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: git rebase fast-forward fails with abbreviateCommands 2020-03-27 15:46 ` Alban Gruin @ 2020-03-27 18:39 ` Elijah Newren 2020-03-27 18:44 ` Jan Alexander Steffens (heftig) 2020-03-28 12:21 ` Alban Gruin 2020-03-27 21:33 ` Junio C Hamano 1 sibling, 2 replies; 11+ messages in thread From: Elijah Newren @ 2020-03-27 18:39 UTC (permalink / raw) To: Alban Gruin Cc: Jan Alexander Steffens (heftig), Git Mailing List, Johannes Schindelin, Phillip Wood 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: git rebase fast-forward fails with abbreviateCommands 2020-03-27 18:39 ` Elijah Newren @ 2020-03-27 18:44 ` Jan Alexander Steffens (heftig) 2020-03-28 12:21 ` Alban Gruin 1 sibling, 0 replies; 11+ messages in thread From: Jan Alexander Steffens (heftig) @ 2020-03-27 18:44 UTC (permalink / raw) To: Elijah Newren Cc: Git Mailing List, Johannes Schindelin, Phillip Wood, Alban Gruin 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: git rebase fast-forward fails with abbreviateCommands 2020-03-27 18:39 ` Elijah Newren 2020-03-27 18:44 ` Jan Alexander Steffens (heftig) @ 2020-03-28 12:21 ` Alban Gruin 1 sibling, 0 replies; 11+ messages in thread From: Alban Gruin @ 2020-03-28 12:21 UTC (permalink / raw) To: Elijah Newren Cc: Jan Alexander Steffens (heftig), Git Mailing List, Johannes Schindelin, Phillip Wood 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: git rebase fast-forward fails with abbreviateCommands 2020-03-27 15:46 ` Alban Gruin 2020-03-27 18:39 ` Elijah Newren @ 2020-03-27 21:33 ` Junio C Hamano 1 sibling, 0 replies; 11+ messages in thread From: Junio C Hamano @ 2020-03-27 21:33 UTC (permalink / raw) To: Alban Gruin Cc: Jan Alexander Steffens (heftig), git, Johannes Schindelin, Elijah Newren, Phillip Wood 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v1 0/2] rebase --merge: fix fast forwarding when `rebase.abbreviateCommands' is set 2020-03-27 11:44 git rebase fast-forward fails with abbreviateCommands Jan Alexander Steffens (heftig) 2020-03-27 15:46 ` Alban Gruin @ 2020-03-30 12:42 ` Alban Gruin 2020-03-30 12:42 ` [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form Alban Gruin 2020-03-30 12:42 ` [PATCH v1 2/2] t3432: test `--merge' with `rebase.abbreviateCommands = true', too Alban Gruin 1 sibling, 2 replies; 11+ messages in thread From: Alban Gruin @ 2020-03-30 12:42 UTC (permalink / raw) To: git Cc: Johannes Schindelin, Elijah Newren, Phillip Wood, Junio C Hamano, jan.steffens, 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form 2020-03-30 12:42 ` [PATCH v1 0/2] rebase --merge: fix fast forwarding when `rebase.abbreviateCommands' is set Alban Gruin @ 2020-03-30 12:42 ` Alban Gruin 2020-03-30 17:50 ` Junio C Hamano 2020-03-30 18:15 ` Eric Sunshine 2020-03-30 12:42 ` [PATCH v1 2/2] t3432: test `--merge' with `rebase.abbreviateCommands = true', too Alban Gruin 1 sibling, 2 replies; 11+ messages in thread From: Alban Gruin @ 2020-03-30 12:42 UTC (permalink / raw) To: git Cc: Johannes Schindelin, Elijah Newren, Phillip Wood, Junio C Hamano, jan.steffens, 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form 2020-03-30 12:42 ` [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form Alban Gruin @ 2020-03-30 17:50 ` Junio C Hamano 2020-03-30 18:15 ` Eric Sunshine 1 sibling, 0 replies; 11+ messages in thread From: Junio C Hamano @ 2020-03-30 17:50 UTC (permalink / raw) To: Alban Gruin Cc: git, Johannes Schindelin, Elijah Newren, Phillip Wood, jan.steffens 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form 2020-03-30 12:42 ` [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form Alban Gruin 2020-03-30 17:50 ` Junio C Hamano @ 2020-03-30 18:15 ` Eric Sunshine 1 sibling, 0 replies; 11+ messages in thread From: Eric Sunshine @ 2020-03-30 18:15 UTC (permalink / raw) To: Alban Gruin Cc: Git List, Johannes Schindelin, Elijah Newren, Phillip Wood, Junio C Hamano, jan.steffens 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> ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v1 2/2] t3432: test `--merge' with `rebase.abbreviateCommands = true', too 2020-03-30 12:42 ` [PATCH v1 0/2] rebase --merge: fix fast forwarding when `rebase.abbreviateCommands' is set Alban Gruin 2020-03-30 12:42 ` [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form Alban Gruin @ 2020-03-30 12:42 ` Alban Gruin 1 sibling, 0 replies; 11+ messages in thread From: Alban Gruin @ 2020-03-30 12:42 UTC (permalink / raw) To: git Cc: Johannes Schindelin, Elijah Newren, Phillip Wood, Junio C Hamano, jan.steffens, 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-03-30 18:15 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-27 11:44 git rebase fast-forward fails with abbreviateCommands Jan Alexander Steffens (heftig) 2020-03-27 15:46 ` Alban Gruin 2020-03-27 18:39 ` Elijah Newren 2020-03-27 18:44 ` Jan Alexander Steffens (heftig) 2020-03-28 12:21 ` Alban Gruin 2020-03-27 21:33 ` Junio C Hamano 2020-03-30 12:42 ` [PATCH v1 0/2] rebase --merge: fix fast forwarding when `rebase.abbreviateCommands' is set Alban Gruin 2020-03-30 12:42 ` [PATCH v1 1/2] sequencer: don't abbreviate a command if it doesn't have a short form Alban Gruin 2020-03-30 17:50 ` Junio C Hamano 2020-03-30 18:15 ` Eric Sunshine 2020-03-30 12:42 ` [PATCH v1 2/2] t3432: test `--merge' with `rebase.abbreviateCommands = true', too Alban Gruin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).