There are lots of questions on this site regarding the behavior of git mv and how to retrieve the history of a file across name boundaries. I understand that Git doesn't actually record the moving/renaming of a file, but I'm not entirely understanding where the problem is with doing so manually.
Suppose I want to rename a file, and I care about keeping its history together. If my workflow is something like
git mv file.txt new_file.txt
<make substantial changes to new_file.txt>
git add new_file.txt
git commit -m "rename and change"
then the history will be broken. The output of git log --follow -- new_file.txt will just be this most recent "rename and change" commit.
However, if I instead use a workflow like
git mv file.txt new_file.txt
git commit -m "rename"
<make substantial changes to new_file.txt>
git add new_file.txt
git commit -m "change"
then it seems like I've averted the break. The output of the same log command now gives me "change", "rename", and any commits that file.txt was involved in before that.
I realize that it's redundant if the file isn't being substantially edited, since Git will deduce the renaming on its own in that case. But in terms of actual nasty problems, the most likely one I could think of is some kind of merge conflict, and I haven't been able to find a situation that goes worse than doing things the regular way.
My question is: Am I missing something? Is there danger lurking somewhere in making an explicit "rename" commit like this?
