# [perf] git log --follow seems slow

2 messages from 2025-06-25 to 2025-06-26. Participants: Kai Koponen, Jeff King.
Thread: https://gitlist.dev/t/63694

## Kai Koponen, 2025-06-25 16:44

Subject: [perf] git log --follow seems slow
Message-ID: <CADYQcGoAN8bW3SVEdqPLJAMQbicbo6wQW_nNa_uYkXMouxO=Ng@mail.gmail.com>
URL: https://gitlist.dev/e/CADYQcGoAN8bW3SVEdqPLJAMQbicbo6wQW_nNa_uYkXMouxO%3DNg%40mail.gmail.com

```
Sample case:
ˋˋˋ
git clone https://github.com/golang/go.git
cd go
git config core.commitGraph true
git commit-graph write --split --reachable --changed-paths
git checkout 3730814f2f2bf24550920c39a16841583de2dac1  # Reproduce HEAD

# Observe that there are no commits to this file until 53fd522
time git rev-list -1 HEAD -- test/index0.go # 0.07s

# Check size of test/index0.go and of 53fd522's diff
wc -l test/index0.go # 12
git show --stat 53fd522c0db58f3bd75d85295f46bb06e8ab1a9b --
test/index0.go # 1 line modified

# Find commit 53fd522 with --follow enabled
time git log --pretty=format:%H --follow --max-count=1 HEAD --
test/index0.go # 2.3s (!)
ˋˋˋ

As far as I can tell, even with all of git's expensive rename and copy
heuristics, the above call shouldn't take this long (nor should higher
max-counts, but count 1 is easier to ballpark the work required):
- There are no other commits touching this file after the target commit.
- Even if some commit after the target commit copied index0.go to
another file, such a commit
  would not need to be included in index0.go's log, so there should be no need
  to do any sort of copy-checking work until index0.go is touched.
- The target commit is not the creation of the file nor is it a > 50%
rewrite of the file, so it should
  not be possible for it to count as a rename or copy, and therefore
no other file blobs should
  need to be checked to confirm this (also, we only requested one
commit, so even if the target
  commit were a rename, in theory there would be no need to check this).

I assume one or more of the following are going on:
- I'm missing some nuance / reason why rename/copy detection is
necessarily more expensive than I think, even for commits that don't
touch the file
- --follow is not taking advantage of the commit graph (seems likely
as --follow seems equally slow with core.commitGraph off)
- --follow is performing expensive rename/copy checks even on small
diffs that are not file creations
- --follow is not using the --max-count target to limit its work
- --follow is not using the --format output to limit its work? (Are
there format options that require more work?)

Git version: 2.50.0.714.g196bf9f422-goog

```

## Jeff King, 2025-06-26 18:52

Subject: Re: [perf] git log --follow seems slow
Message-ID: <20250626185216.GB17172@coredump.intra.peff.net>
URL: https://gitlist.dev/e/20250626185216.GB17172%40coredump.intra.peff.net
In-Reply-To: <CADYQcGoAN8bW3SVEdqPLJAMQbicbo6wQW_nNa_uYkXMouxO=Ng@mail.gmail.com>

```
On Wed, Jun 25, 2025 at 12:44:16PM -0400, Kai Koponen wrote:

> - --follow is not taking advantage of the commit graph (seems likely
> as --follow seems equally slow with core.commitGraph off)

It's mostly this. History pruning is disabled with --follow, since the
path of interest may change as we traverse through history. And the use
of commit graph changed-path bloom filters is tied to the pruning code.
So this hits you two-fold:

  1. For each commit we visit, we actually do a tree diff to see if it
     touched that path (leaving aside rename detection, we still have to
     open the trees down to the path of interest).

  2. We don't prune side-branches of history, so we are visiting more
     commits. Normally when we see a merge of two branches, when one
     parent matches the merge result and the other does not, we know
     that nothing interesting happened on the side branch. So we do not
     traverse those commits at all. But with pruning disabled, that no
     longer happens.

These limitations are mostly due to the hacky way that --follow is
bolted on to the traversal machinery. The "right" way for --follow to
work is to keep a unique pathspec (and bloom filter) for each line of
commits, passing it down as we walk backwards through history (and
modifying it when we see a rename).

It's probably possible to bolt bloom-filter checks onto the existing
--follow feature, but it would probably involve a lot of special casing.

-Peff

```