Re: Proposal: tell git a file has been renamed

From: Erik Cervin Edin <erik@cervined.in>
Date: Apr 24, 2023, 10:49 UTC
Message-ID: <CA+JQ7M-1YvZFzE_CtBQa5_eEXa1sPqK4xsTxdwpAQo_YcmW+-A@mail.gmail.com>
In-Reply-To: <74a361fd-4ee6-f362-8d49-92417f0e2dac@game-point.net>

On Mon, Apr 24, 2023 at 12:21 PM Jeremy Morton <admin@game-point.net> wrote:

>
> I'm surprised --follow isn't the default, actually... isn't the whole
> point of detecting renames to allow content history to be tracked back
> through renames?

You can set log to --follow by default
  If true, git log will act as if the --follow option was used when a
single <path> is given.
  This has the same limitations as --follow, i.e. it cannot be used to
follow multiple files
  and does not work well on non-linear history.
  https://git-scm.com/docs/git-log#Documentation/git-log.txt-logfollow

The reason it's not default is probably those limitations.

Show 5 quoted lines

>
> Another one that jumped to mind for me is bisect.  As rename-only
> commits are liable to create broken builds, it should skip over them
> to the 'content' commit.
>

I always find this to be the main dilemma. I try to make commits as discrete changes but it's not always possible with renames. Sometimes, renaming a file changes it so much that the rename detection doesn't work by default. There are also other problems that arise when reordering commits and changes in a feature branch. I've found that the safest thing is to split renames out into discrete commits and only do 100% renames.