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

Can git log be made to "follow" in the same way as git blame? Why / in what way is "--follow" broken or limited?

From
Tao Klerks <tao@klerks.biz>
Date
Aug 26, 2024, 19:00 UTC
Message-ID
<CAPMMpogApZ6VN9sYxgmtHCickkstM6HZq1teeAa+a2t1_BY0sQ@mail.gmail.com>
Hi folks,

I've been working on a "git blame optimizer for partial clone repos", following up on a thread with Derrick Stolee from 2021 ( https://lore.kernel.org/git/0b57cba9-3ab3-dfdf-5589-a0016eaea634@gmail.com/ ), with the intention to pre-fetch all locally-missing blobs for a given file in the history of a branch/commit, and it ended up being much more complex to do that I expected, basically because "git log --follow -- SOMEFILE" doesn't return all the commits containing versions of "SOMEFILE" that "git blame" will end up visiting.

I thought this strange/interesting, because (as far as I can tell), as long as there are no renames in the history of the file, "git log -- SOMEFILE", without the "--follow", *does* seem to return all the commits containing unique versions of the file.

The only reference to this weirdness that I could find in the doc, after ripping my hair out for a few hours, was in a note on "log.follow" config, under the "git log" doc eg at https://git-scm.com/docs/git-log : "This has the same limitations as --follow, i.e. it cannot be used to follow multiple files and does not work well on non-linear history."

What seems weird and interesting to me, is that whatever is going "wrong" in "git log --follow" doesn't happen in "git blame". I couldn't find an easy way to demo/prove it, but I found experimentally that the set of blobs examined by "git blame" (and fetched just-in-time if-needed in a partial clone) is larger than the set of blobs in commits output by "git log --follow -- FILENAME", but not larger than the set of blobs in commits output by "git log -- FILENAME" (for a file that has not been renamed).

You can see the strange effect that "--follow" has by comparing a run with and without on "git.c" in the git project for example - a file that was never renamed:

git log --pretty='%H' -- git.c | sort | uniq > ~/test1 # 717 commits git log --pretty='%H' --follow -- git.c | sort | uniq > ~/test2 # 537 commits

You'll find that with "--follow", you get a couple extra commits, and a whole bunch missing. You can try to fill them in with "--full-history" etc, but while such options are *accepted*, they are also completely and utterly *ignored*.

Insofar as this is a known issue... is there an intelligible reason for it? Should be something we aspire to fix, or should the doc be improved to make it more obvious what this option does and doesn't do?

Thanks, Tao

Next: Junio C Hamano
Message 1 of 3 in “Can git log be made to "follow" in the same way as git blame? Why / in what way is "--follow" broken or limited?”
  1. Tao KlerksAug 26, 2024
  2. Junio C HamanoAug 26, 2024
  3. Junio C HamanoAug 26, 2024

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.