Re: Renaming files with git not all that bad?

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 09 Dec 2021 16:56:05 +1300
> From: Phil Sainty <psainty@orcon.net.nz>
> Cc: Mathias Dahl <mathias.dahl@gmail.com>, emacs-devel@gnu.org
> 
> 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).

The problem is not with deciding a change is a rename, the problem is
with following the rename in a way that is useful for whatever Git
command you are invoking.

> 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.

Some Git commands don't have the --follow switch, AFAIR, or have it in
a way that forbids using other useful options.  So renaming still has
its downsides, albeit they aren't catastrophic nor affect every single
Git feature.