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 <admin@xxxxxxxxxxxxxx> 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
