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

On 10/06/2026 12:00, betel_taxis4h@icloud.com wrote:

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/