Is it possible to move/rename files in Git and maintain their history?
Solution 1:
Git detects renames rather than persisting the operation with the commit, so whether you use git mv
or mv
doesn't matter.
The log
command takes a --follow
argument that continues history before a rename operation, i.e., it searches for similar content using the heuristics:
http://git-scm.com/docs/git-log
To lookup the full history, use the following command:
git log --follow ./path/to/file
Solution 2:
No.
The short answer is NO. It is not possible to rename a file in Git and remember the history. And it is a pain.
Rumor has it that git log --follow
--find-copies-harder
will work, but it does not work for me, even if there are zero changes to the file contents, and the moves have been made with git mv
.
(Initially I used Eclipse to rename and update packages in one operation, which may have confused Git. But that is a very common thing to do. --follow
does seem to work if only a mv
is performed and then a commit
and the mv
is not too far.)
Linus says that you are supposed to understand the entire contents of a software project holistically, not needing to track individual files. Well, sadly, my small brain cannot do that.
It is really annoying that so many people have mindlessly repeated the statement that Git automatically tracks moves. They have wasted my time. Git does no such thing. By design(!) Git does not track moves at all.
My solution is to rename the files back to their original locations. Change the software to fit the source control. With Git you just seem to need to "git" it right the first time.
Unfortunately, that breaks Eclipse, which seems to use --follow
. git log --follow
sometimes does not show the full history of files with complicated rename histories even though git log
does. (I do not know why.)
(There are some too clever hacks that go back and recommit old work, but they are rather frightening. See GitHub-Gist: emiller/git-mv-with-history.)
In short: if Subversion doing this is wrong, then Git doing this is also wrong - doing this isn't some (mis!)feature, it's a mistake.