Ref list fails to load in gitk when stale tracking reference exists

Thank you for filling out a Git bug report! Please answer the following questions to help us understand your issue.

What did you do before the bug happened? (Steps to reproduce your issue) Open gitk and use F2 to list refs while remote-merged branch is in view that still exists locally (and has a tracking reference in .git/config).

What did you expect to happen? (Expected behavior) The list of refs opens, so I can see reachable tags.

What happened instead? (Actual behavior) An error pops up, dismissing it leaves the list of refs empty.

What's different between what you expected and what actually happened?
This error message:
---------
can't read "headids(remotes/origin/testing)": no such element in array
can't read "headids(remotes/origin/testing)": no such element in array
    while executing
"commitinview $headids($upstreamofref($n)) $curview"
    (procedure "refill_reflist" line 16)
    invoked from within
"refill_reflist"
    (procedure "showrefs" line 44)
    invoked from within
"showrefs"
    (command bound to event)
---------

remotes/origin/testing is a branch that existed upstream, but was
since merged and deleted.
The local one still exists (pending deletion/cleanup), but has a
tracking reference
in .git/config:
---------
[branch "testing"]
    remote = origin
    rebase = true
    merge = refs/heads/testing
---------

Anything else you want to add: This wasn't the case with an earlier version of Git on a decommissioned machine. git version 2.42.0.windows.2 is known good (but 2 years old).

Please review the rest of the bug report below. You can delete any lines you don't wish to share.

[System Info]
git version:
git version 2.51.0.windows.1
cpu: x86_64
built from commit: 4d21a77b98af5cf479d8b6f863c2aa94257cd4e1
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
feature: fsmonitor--daemon
libcurl: 8.15.0
OpenSSL: OpenSSL 3.2.4 11 Feb 2025
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Windows 10.0 26100
compiler info: gnuc: 15.2
libc info: no libc information available
$SHELL (typically, interactive shell): C:\Program Files\Git\usr\bin\bash.exe

[Enabled Hooks]

Am 15.11.25 um 13:33 schrieb BhaaL:

This is fixed in the gitk that is included in Git v2.52.0.

-- Hannes

Awesome, thanks for letting me know!
I've sat on this report for a while, and only just gotten to send it
off (after an update to 2.51.2 still had the issue).
- BhaaL

On Sat, Nov 15, 2025 at 11:01 PM Johannes Sixt <j6t@kdbg.org> wrote: