From: Jeremy Morton Date: Mon, 24 Apr 2023 14:42:04 GMT Subject: Re: Proposal: tell git a file has been renamed Message-ID: In-Reply-To: Yep, and that suggestion is rather arduous compared to something like: git markasrenamed file2 file1 git commit -- Best regards, Jeremy Morton (Jez) On 24/04/2023 15:00, Erik Cervin Edin wrote: > On Mon, Apr 24, 2023 at 1:17 PM Jeremy Morton wrote: >> >> 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. > > It can definitely be both arduous and non-obvious how to deal with this. > > The problem is that such a command cannot exist atm. because renames > don't exist, they are only interpreted. So the only way to achieve > this is to revert enough of the contents staged to the index such that > the rename is detected. The only way to do that in a foolproof manner > is reverting all the staged changes except the path so that the moved > file in the index is identical to the old file in HEAD. > > If I understand you correctly, your point here is that it's > non-trivial to go from a state where a file has been renamed, with > enough changes staged into the index that the rename hasn't been > detected, to a state where the rename is recorded in the index? > > The most straightforward method I can think of to restore the staged > changes, do the rename without changes, commit and then go about the > rest > eg: > git restore --staged file2 > mv file2 file1 > git mv file1 file2 > git commit -m rename >