If we ever moved a file to a different location or renamed it, all its previous history is lost in git log
, unless we specifically use git log --follow
Presumably it's because git log
is generally used for displaying overall commit histories, and not the history of a single file or path. The --follow
option is only relevant if you're looking at a single file (and doesn't work when you name more than one file). Since that's not the most common case, it doesn't really make sense to add it as the default.
If you want to make it a default for yourself, you can always make an alias:
git config --global alias.lf 'log --follow'
Now you can do git lf <filename>
to get the behavior you want.
Note: If you want to propose the change you're asking for to the mailing list and see what people think, you can do that here. Or, even better, you could submit a patch!
Note: starting git 2.6 (Q3 2015), git log can follow the history by default for a file!
See commit 076c983 (08 Jul 2015) by David Turner (dturner-tw).
(Merged by Junio C Hamano -- gitster -- in commit 2dded96, 03 Aug 2015)
log
: add "log.follow
" configuration variablePeople who work on projects with mostly linear history with frequent whole file renames may want to always use "
git log --follow
" when inspecting the life of the content that live in a single path.Teach the command to behave as if "
--follow
" was given from the command line whenlog.follow
configuration variable is set and there is one (and only one) path on the command line.
git config log.follow true
Note: there is also a (strangely not documented still in 2020 and Git 2.25) --no--follow
option, which can override a log.follow
config setting.
Vser is proposing a patch.
Jeff King (peff) points out the same commit I mentioned in the discussion: commit aebbcf5, Git 1.8.2, Sept. 2012, where --no-follow
was introduced.