Git renaming file. History is available on cmd-line, but not in github interface?

Question

There have been many excellent posts on how to preserve history when renaming files and folders in Git.

---

This works on the git command-line interface:

#if you don't modify oldname.cpp or newname.cpp, git will understand your rename

git mv old.cpp new.cpp
git commit -am "renamed old.cpp -> new.cpp"

git log new.cpp #only shows the new commit
git log --follow new.cpp #shows ALL the history of old.cpp and new.cpp

Great, so the --follow command allows us to get all the history of new.cpp after it's been renamed. This works great in the command-line interface to git.

---

But, in the github web interface, the history of old.cpp doesn't show up for new.cpp. This is a problem, because many of my team members see their github accounts as a part of their resumes. If their commits don't show up in github after renaming files, they're losing resume points. After a major filename/directory restructuring, a contributor can end up not having a single visible commit on a repo.

How do I get the full file history to show up in the github web interface (e.g. git log --follow) after renaming files?

Or I am I stuck never renaming anything, unless I'm willing for casual github users to never see the old commits?

Answer 1

As you are probably aware from those three questions you linked, there is nothing in Git that tracks a file move. For Git it is just a file being removed, and another file being added. Only the frontend does some recognition of file moves based on the similarity of the contents. So, if GitHub does not provide tracking of changes to a file which might have been moved before, there is not really much you can do about it other than to ask GitHub to work on that.

That being said, your statement that a file move will make a contributor end up without visible commits is false. Yes, if I look at the history of a single file that was removed before, then this might seem like it, but, as you might now, Git does not forget a thing that happened in the repository. And the log for the repository will still contain every single commit that’s visible from a given branch. And that obviously also includes commits that happened before files were moved (because Git tracks content, not changes). You can usually get the commit log at https://github.com/<user>/<project>/commits/<branch>.

And here comes another point: The log includes only those commits, that are visible from the given branch. So if you work on multiple branches, this whole thing is rather stupid anyway. If you want to get some idea of how much a contributor works on a project, you should use the project graphs at https://github.com/<user>/<project>/graphs/contributors.

But of course, measuring commit count is not a good metric anyway (same with things like LOC ratio).