take care when renaming files in git
If you rename and modify a file in the same commit, you will loose its history:
http://sourceware.org/ml/frysk/2008-q1/msg00004.html
You have to do a commit just with the rename operation (identical file contents), and then modify it. Sheesh, good to know about that!
I recall I had a similar problem with Subversion once… I think it was refusing my commit or something. I had to go back and do just the rename, commit and then modify the file.
Friday, May 16, 2008 at 16:31
This probably isn’t such a big problem in practice. Even though the commit doesn’t record renames, gitk automatically notices the similarities and can show a good diff, reporting the rename. I imagine similar logic is used when merging, but have never tried.
Was pleased to notice this after doing a big refactor of some Java code in eclipse then git add … ; git remove … ; git commit.
Cheers,
Rodney
Sunday, May 18, 2008 at 10:44
My worry is about git log. Does it have such logic? That’s what prompted the e-mail conversation I refer to.
But Andrew Cagney said he re-indented the file before committing, so possibly git’s logic thought the old and new files were too different.
So the thing is, you should not change (or change very little) the file before committing the move.
Thursday, February 5, 2009 at 09:18
Yes, use “git log -M -p” and you will see if a file was renamed. You’ll also see the “small” diff between the old and the new contents if there were any differences beside the renaming.