Re: Proposal: tell git a file has been renamed

From: Jeremy Morton <admin@game-point.net>
Date: Apr 24, 2023, 11:17 UTC
Message-ID: <91dab444-5f65-31ae-c0c6-0b84313bcd94@game-point.net>
In-Reply-To: <CA+JQ7M-1YvZFzE_CtBQa5_eEXa1sPqK4xsTxdwpAQo_YcmW+-A@mail.gmail.com>

On 24/04/2023 11:49, Erik Cervin Edin wrote:

Show 9 quoted lines

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

There's no getting away from the fact that this adds a lot of (IMHO unnecessary) work if you've already done a rename that git can't detect and have both that and a bunch of other changes sitting in the index. What feels like it would be a natural resolution in these cases, though, is a "no, this remove/add is actually a rename" command.

-- 
Best regards,
Jeremy Morton (Jez)