Renaming files with git not all that bad?

[Stefan Kangas]

Stefan Kangas <stefan@marxist.se> writes:

> The big drawback here is that we will lose the git history.

I tested this just now, and unless I'm missing something, a rename
actually doesn't have to be all that bad.  It turns out that
vc-annotate, magit-blame and vc-region-history have little trouble
handling a rename if its done properly.

In any case, I made a commit containing no other changes than

    git mv lisp/image-dired.el lisp/image

and in the new file, I get history and blame in the new file all the way
back to 2007, when the file was last renamed.

Even vc-print-log works, but I first have to say

    (setq vc-git-print-log-follow t)

though that option is not without its caveats (it skips merge commits).
(See the comment in vc-git.el.)

The key thing seems to be making sure to make no other changes than the
actual moving of the file in a single commit.  This is to make it easy
for the git heuristics to notice that the file was moved.  And then most
of the stuff we care about will work seamlessly, or nearly seamlessly as
seems to be the case with vc-print-log.

It looks like CONTRIBUTE already has the necessary advice here (though I
have no idea why it's talking about creating a feature branch, which
doesn't seem necessary).

I'm not sure if this is new to anyone else than me, but I was positively
surprised with how well git handled this.  I'm not sure if I just never
figured out to do this properly, if git got better, or what.