Preserving History When Renaming Files in git

You create a file somewhere called mind-blowing-blog-post.md and get writing. You commit, work, commit, work, commit. Then, git log 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 accurate, like 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 git log for this.

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.

comments powered by Disqus