* [BUG] rebase --update-refs emits unqualified "update-ref HEAD" into the todo
@ 2026-06-10 11:00 betel_taxis4h
2026-06-10 15:39 ` Phillip Wood
0 siblings, 1 reply; 2+ messages in thread
From: betel_taxis4h @ 2026-06-10 11:00 UTC (permalink / raw)
To: git
What did you do before the bug happened? (Steps to reproduce your issue)
With rebase.updateRefs=true, an interactive rebase of the checked-out branch generates a todo containing the literal line "update-ref HEAD”, which git's own todo parser then rejects.
Minimal reproduction (plain repo, no worktrees, no remotes required):
git init -b main repro && cd repro
git -c user.email=t@t.t -c user.name=t commit --allow-empty -m base
git checkout -b feat
git -c user.email=t@t.t -c user.name=t commit --allow-empty -m c1
git -c user.email=t@t.t -c user.name=t commit --allow-empty -m c2
git -c rebase.updateRefs=true rebase -i feat~2
The generated todo contains:
pick <c1> c1
pick <c2> c2
update-ref HEAD <-- emitted for HEAD, a symref to the branch being rebased
update-ref refs/heads/feat (correctly placed; this one is fine)
Letting the editor save the auto-generated todo verbatim (or running `git rebase --continue`) fails immediately with:
error: update-ref requires a fully qualified refname e.g. refs/heads/HEAD
error: invalid line 3: update-ref HEAD
You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
What did you expect to happen? (Expected behavior)
--update-refs should not emit an "update-ref HEAD" line. HEAD is a symbolic alias of the branch being rebased; the branch ref itself is (correctly) excluded from the update-ref set, so its HEAD alias should be excluded too. The todo should contain only fully-qualified refs/heads/... lines.
What happened instead? (Actual behavior)
git emits a todo line ("update-ref HEAD") that its own sequencer parser rejects as not fully qualified, breaking the rebase. The only recovery is `git rebase --edit-todo` to manually delete the line.
What's different between what you expected and what actually happened?
git generated a todo command it refuses to execute. The unqualified "HEAD" should either be expanded to its target ref or omitted entirely.
Anything else you want to add:
- Reproduces identically in a plain single-worktree repo and in a bare-repo + linked-worktree layout, so it is not worktree-specific.
- An in-sync remote-tracking ref (origin/feat) on the tip adds a second, valid "update-ref refs/remotes/origin/feat" line but is not required to trigger the fatal "update-ref HEAD".
- Workaround: unset rebase.updateRefs (or pass -c rebase.updateRefs=false), or delete the "update-ref HEAD" line via `git rebase --edit-todo`.
[System Info]
git version:
git version 2.54.0
cpu: aarch64
no commit associated with this build
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: disabled
gettext: enabled
libcurl: 8.14.1
OpenSSL: OpenSSL 3.5.6 7 Apr 2026
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Linux 7.0.11-orbstack-00360-gc9bc4d96ac70 #1 SMP PREEMPT Thu Jun 4 16:40:25 UTC 2026 aarch64
compiler info: gnuc: 14.2
libc info: glibc: 2.41
$SHELL (typically, interactive shell): /usr/bin/zsh
^ permalink raw reply [flat|nested] 2+ messages in thread* Re: [BUG] rebase --update-refs emits unqualified "update-ref HEAD" into the todo
2026-06-10 11:00 [BUG] rebase --update-refs emits unqualified "update-ref HEAD" into the todo betel_taxis4h
@ 2026-06-10 15:39 ` Phillip Wood
0 siblings, 0 replies; 2+ messages in thread
From: Phillip Wood @ 2026-06-10 15:39 UTC (permalink / raw)
To: betel_taxis4h, git
On 10/06/2026 12:00, betel_taxis4h@icloud.com wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> With rebase.updateRefs=true, an interactive rebase of the checked-out branch generates a todo containing the literal line "update-ref HEAD”, which git's own todo parser then rejects.
>
> Minimal reproduction (plain repo, no worktrees, no remotes required):
>
> git init -b main repro && cd repro
> git -c user.email=t@t.t -c user.name=t commit --allow-empty -m base
> git checkout -b feat
> git -c user.email=t@t.t -c user.name=t commit --allow-empty -m c1
> git -c user.email=t@t.t -c user.name=t commit --allow-empty -m c2
> git -c rebase.updateRefs=true rebase -i feat~2
>
> The generated todo contains:
>
> pick <c1> c1
> pick <c2> c2
> update-ref HEAD <-- emitted for HEAD, a symref to the branch being rebased
> update-ref refs/heads/feat (correctly placed; this one is fine)
I'm unable to reproduce this with the script above and I do not see any
update-ref commands added to the todo list (which is expected as feat is
being rebased so should not appear in the todo list). Do you have
rebase.instructionFormat set? We recently had a bug report and fix[1]
for "update-ref HEAD" being added when rebase.instructionFormat includes
"%d".
Thanks
Phillip
[1] https://lore.kernel.org/git/20260510224111.64467-1-mail@abhinavg.net/
> Letting the editor save the auto-generated todo verbatim (or running `git rebase --continue`) fails immediately with:
>
> error: update-ref requires a fully qualified refname e.g. refs/heads/HEAD
> error: invalid line 3: update-ref HEAD
> You can fix this with 'git rebase --edit-todo' and then run 'git rebase --continue'.
>
> What did you expect to happen? (Expected behavior)
>
> --update-refs should not emit an "update-ref HEAD" line. HEAD is a symbolic alias of the branch being rebased; the branch ref itself is (correctly) excluded from the update-ref set, so its HEAD alias should be excluded too. The todo should contain only fully-qualified refs/heads/... lines.
>
> What happened instead? (Actual behavior)
>
> git emits a todo line ("update-ref HEAD") that its own sequencer parser rejects as not fully qualified, breaking the rebase. The only recovery is `git rebase --edit-todo` to manually delete the line.
>
> What's different between what you expected and what actually happened?
>
> git generated a todo command it refuses to execute. The unqualified "HEAD" should either be expanded to its target ref or omitted entirely.
>
> Anything else you want to add:
>
> - Reproduces identically in a plain single-worktree repo and in a bare-repo + linked-worktree layout, so it is not worktree-specific.
> - An in-sync remote-tracking ref (origin/feat) on the tip adds a second, valid "update-ref refs/remotes/origin/feat" line but is not required to trigger the fatal "update-ref HEAD".
> - Workaround: unset rebase.updateRefs (or pass -c rebase.updateRefs=false), or delete the "update-ref HEAD" line via `git rebase --edit-todo`.
>
>
> [System Info]
> git version:
> git version 2.54.0
> cpu: aarch64
> no commit associated with this build
> sizeof-long: 8
> sizeof-size_t: 8
> shell-path: /bin/sh
> rust: disabled
> gettext: enabled
> libcurl: 8.14.1
> OpenSSL: OpenSSL 3.5.6 7 Apr 2026
> zlib: 1.3.1
> SHA-1: SHA1_DC
> SHA-256: SHA256_BLK
> default-ref-format: files
> default-hash: sha1
> uname: Linux 7.0.11-orbstack-00360-gc9bc4d96ac70 #1 SMP PREEMPT Thu Jun 4 16:40:25 UTC 2026 aarch64
> compiler info: gnuc: 14.2
> libc info: glibc: 2.41
> $SHELL (typically, interactive shell): /usr/bin/zsh
>
>
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-06-10 15:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-10 11:00 [BUG] rebase --update-refs emits unqualified "update-ref HEAD" into the todo betel_taxis4h
2026-06-10 15:39 ` Phillip Wood
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox