If you have a file and you want to know when it was renamed...
git log --follow --summary --format= <filename>--follow will continue listing history through renames. --format= suppresses the usual output. --summary shows when the file was created, renamed, or its permissions changed.
$ git log --follow --summary -w --format= baz rename bar => baz (100%) rename foo => bar (100%) create mode 100644 fooThe original name of this file was foo. It was renamed to bar with no content changes. Then renamed again to baz with no content changes.
Note: Git does not track renames. Instead it uses heuristics to look for similar files. A simple git mv like in the history above is easy for Git to follow. However, if you rename a file and alter it in one commit, Git might not be able to follow the rename. It depends on how much was altered and how hard you tell Git to look.
By default it looks for files with at least 50% similarity. You can affect this with -M and -l.
For example, here I git mv baz blat and also added a line and made some whitespace changes.
commit 3c3240d16866a91b499fe17d478b82277c83adedAuthor: Michael G. Schwern <schwern@pobox.com>Date: Fri May 10 12:22:59 2024 -0700 mv baz blat, add thisdiff --git a/baz b/blatsimilarity index 37%rename from bazrename to blatindex dfa74aa..43b1a69 100644--- a/baz+++ b/blat@@ -1,4 +1,7 @@ this+that+ other-thing++ thing This resulted in a similarity threshold below 50%. I need to lower Git's standards for looking for renames to 30%.
$ git log --follow --summary --format= blat create mode 100644 blat$ git log --follow --summary --format= -M.3 blat rename baz => blat (37%) rename bar => baz (100%) rename foo => bar (100%) create mode 100644 fooBecause this is a heuristic, Git can get it wrong. You still need to verify.
For this reason, if you need to rename a file and then change a significant portion of the file (and if it's a very small file any change can be significant) it's good practice to rename in one commit and alter in another, even if this results in a broken commit.