[perf] git log --follow seems slow

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

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

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