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
. I think usually, the expected behavior is that we'd like to see the past history too, not "cut off" after the rename or move, so is there a reason why git log
doesn't default to using the --follow
flag?

- 146,324
- 131
- 460
- 740
-
3Git 2.6+ (Q3 2015) will propose `git config log.follow true` for that: see [my answer below](http://stackoverflow.com/a/32039661/6309) – VonC Aug 16 '15 at 20:35
2 Answers
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.
-
2One big caveat is that `follow=true` hides merge commits in innocent-looking commands like `git log -- ./subproject`. Almost feels like a Git bug but it's doing it consistently across operating systems and versions so maybe I'm misunderstanding what `--follow` should do when given a pathspec that is a directory. – Borek Bernard Jun 06 '18 at 09:43
-
@BorekBernard Good point. I haven't tested that command often with folders. – VonC Jun 06 '18 at 12:18
-
1Since there is no `--no-follow` option, is there a way to override this option without changing it? Use case is similar to [this one](https://stackoverflow.com/a/27851219/2622010) (see eg comment to the answer). – Vser Jan 31 '20 at 14:32
-
1@Vser Sure, for one command: `git -c log.follow= log`: that will unset `log.follow`, just for that one `git log` instance. – VonC Jan 31 '20 at 14:44
-
-
@Vser Yes, that would a good idea. I don't see it discussed on the Git mailing-list already: https://public-inbox.org/git/?q=log+no-follow – VonC Jan 31 '20 at 16:46
-
And yet [t4202-log.sh](https://github.com/git/git/blob/master/t/t4202-log.sh#L169) tests this and git do recognizes the argument. The bug might then be in the documentation :) – Vser Jan 31 '20 at 20:56
-
@Vser True. This comes from the commit I mention in the answer. Discussed in https://public-inbox.org/git/xmqqpp3zk9nm.fsf@gitster.dls.corp.google.com/T/#u. – VonC Jan 31 '20 at 22:20
-
Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/207004/discussion-between-vser-and-vonc). – Vser Jan 31 '20 at 22:31
-
1
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!

- 303,634
- 46
- 339
- 357
-
aha, so if it is a single file, maybe it'd make sense to default to `--follow`. The reason that it doesn't follow more than one file is probably due to speed reasons? – nonopolarity Aug 27 '12 at 23:40
-
@動靜能量: I don't want to speculate, but that seems unlikely. git allows you to do many options that would be very expensive to calculate (e.g. complex rebases and so on). – John Feminella Aug 27 '12 at 23:52