Re: Renaming files with git not all that bad?

[Phil Sainty <psainty@orcon.net.nz>]

On 2021-12-09 16:20, Stefan Kangas wrote:
> 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.

That's the right process IMO.  If ever I'm going to rename a
file which has uncommitted changes, I'll stash my changes and
introduce a separate rename commit for the original file content
before continuing, for the exact reason of maximising Git's
ability to detect it.

Git does seem fairly good at calling things a rename even if
I've forgotten to do it separately -- it seems to notice when
the old and the new are very similar, and make the assumption --
but if the old and new files are literally the same then Git
will be dealing with an identical hash for that blob; and so if
a commit is deleting a filename for that blob and also adding
a filename for the identical blob, Git doesn't have to work
very hard to decide that it's a rename!  (For the same reason
I would assume that it's also more efficient to follow renames
when they are done this way).

It should be noted that (IIRC) it isn't *default* behaviour for
Git to follow changes across renames[1], but AFAIK the "--follow"
option is the typical way to ask it to do so, and the likes of
vc and magit can ensure that this is used automatically in cases
where it's necessary.

[1] Not for all commands, at least.  Offhand I know that git
blame does follow renames by default, and there might be others.


-Phil