You create a file somewhere called
mind-blowing-blog-post.md and get writing.
You commit, work, commit, work, commit. Then,
mind-blowing-blog-post.md should show three commits for that file, right? Yep.
After working for a bit, you decide to change its name to something more
just-an-average-blog-post.md, and you commit the change.
But, then you take a break, and you think a few commits
ago this post was actually mind–blowing. So you decide to look at your commits
to see what went wrong.
git log just-an-average-blog-post.md—oh no! Where
did all those commits go?
This very thing has been bugging me for awhile. I wanted to settle it once and
for all. I thought for sure I was doing something wrong, like I should be
renaming files with
git mv or something. Nope that’s not it.
Turns out, I’m not doing anything wrong. Git figures out file renames just fine on its own, because…
Remember, git tracks content, not files
Git doesn’t really care that we renamed the file, but it knows that we moved the contents of the file to another file. When we tell git to show us the history for a particular file name, it will only show us the history for that file, not the entire history for the content within the file.
In order to see the entire history for that content, we need to tell git that’s
specifically what we want. There’s a
--follow option we can pass to
So, to see our commits before the rename, we can do
git log --follow
just-an-everage-blog-post.md and voila, there’s our entire history for the
content of that file.
I wish there was a way to get this through the Github web interface, because I look at file history often there, but at least now I know its possible on the command line.