git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[perf] git log --follow seems slow

From
Kai Koponen <kaikoponen@google.com>
Date
Jun 25, 2025, 16:44 UTC
Message-ID
<CADYQcGoAN8bW3SVEdqPLJAMQbicbo6wQW_nNa_uYkXMouxO=Ng@mail.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
Next: Jeff King
Message 1 of 2 in “[perf] git log --follow seems slow”
  1. Kai KoponenJun 25, 2025
  2. Jeff KingJun 26, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.