On Sun, May 24, 2020 at 10:05:28AM -0700, Linus Torvalds wrote:
Sasha mentioned "--follow", which also happens to show that commit,
but that's more of an incidental happenstance than anything else. "git
log --follow" is kind of a special case, where git stops doing some of
the pathname-based simplifying, because if the file shows up from
nothing, git will try to then figure out where it came from. The fact
that "--follow" this ends up not pruning irrelevant history as
aggressively is more of an implementation artifact than anything else.
So generally, don't use "--follow". It's kind of a hack to emulate
"track changes to a file", but it is a hack, and it fundamentally is a
bogus operation (for all the same reasons that the CVS/SCCS/SVN/etc
notion of a "file identity" is complete garbage and leads to
fundamental problems).
Interesting. My thinking around --follow was that it's like
--full-history in the sense that it won't prune history, but it would
also keep listing history beyond file renames.
The --follow functionality is quite useful when looking at older
branches and trying to understand where changes should go into on those
older branches.
We also do have some notion of "file identity" in the kernel; it's
prevalent with "quirk files". Look at these for example:
- drivers/mmc/core/quirks.h
- sound/pci/hda/patch_*.c
- drivers/hid/hid-quirks.c
We know that patches to those files are likely to contain quirks (which
we usually want to take into the Stable branches) so I might have a
script that monitors a list of these "special" files in which case I
need to see a complete list of commits that went into those files.