bugreport: performance regression on git log --follow

[b.murauer@posteo.de]

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)

I ran git log --follow on a single file in a repository with about 30k 
commits
and 27k tracked files:

     git log --follow --oneline -- path/to/file.ts >/dev/null

VS Code's Timeline view runs a similar command automatically:

     git log --no-ext-diff --no-textconv --format=<format> -z -n551 
--shortstat \
         --follow -- path/to/file.ts

We regularly merge older maintenance branches forward into main. The 
affected
file was added on main and does not exist on those branches, so many 
merges have
a parent that lacks it. The following command reports 692 commits for 
this file:

     git log --full-history -m --diff-filter=A --format=%h -- 
path/to/file.ts |
         sort -u | wc -l

What did you expect to happen? (Expected behavior)

I expected the command to finish in a time comparable to earlier Git 
versions.
With Git 2.43 on the same history, it takes about 1 second.

What happened instead? (Actual behavior)

With Git 2.56, the command takes around 10 minutes. It uses one CPU core
for the whole run, with very little system time, and output appears 
slowly.

Bisecting between v2.43.0 and v2.56.0 identified this commit:

     304812ed33 (log: improve --follow following renames for non-linear 
history)

What's different between what you expected and what actually happened?

The command is around 600 times slower than with Git 2.43 and is 
effectively
unusable for this file. The output of the newer version may also 
legitimately
differ on non-linear history, but the slowdown is the problem being 
reported.

Anything else you want to add:

perf report for a 20-second sample with Git 2.56:

     24.67%  hash_chars
     10.37%  spanhash_cmp
      9.91%  0x0000000000043558
      4.90%  zng_inflate
      2.89%  bsearch_hash
      1.86%  dowild
      1.45%  diffcore_count_changes

This points to rename detection. My understanding is that the commit now 
runs a
follow-enabled diff against each parent of a merge. If that parent lacks 
the
file, Git looks for a rename source across that parent's tree. This 
happens at
every such merge, so the cost grows with the number of forward merges 
and the
size of the tree.

Things I ruled out:
- The repository is a full clone, not shallow or partial, with no 
missing objects.
- It is freshly packed: 0 loose objects, 2 packs, about 1.37M objects, 
543 MiB.
- Disabling the commit-graph with core.commitGraph=false does not help.
- Ignoring global and system config does not help.
- Git LFS is not involved: GIT_TRACE shows no external processes being 
launched.
- Setting diff.renameLimit=1 does not fix it: the command still takes 
over a minute.

I have a bash script that reproduces the issue, if needed. I'm not sure 
if
such things should be shared via this channel.

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.56.0
cpu: x86_64
built from commit: a018953688f1b10bddf91bff8747068f5f4746a4
sizeof-long: 8
sizeof-size_t: 8
shell-path: /bin/sh
rust: enabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.22.0
OpenSSL: OpenSSL 3.6.4 25 Aug 2026
zlib-ng: 2.3.3
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
uname: Linux 7.2.14-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 30 Oct 2026 
14:32:40 +0000 x86_64
compiler info: gnuc: 16.2
libc info: glibc: 2.44
$SHELL (typically, interactive shell): /usr/bin/fish


[Enabled Hooks]
not run from a git repository - no hooks to show