On Sat, Apr 22, 2023 at 9:57 PM Jeremy Morton <admin@xxxxxxxxxxxxxx> wrote: > > https://stackoverflow.com/a/1094392/178757 > > says: > > git mv oldname newname > > is just shorthand for: > > mv oldname newname > git add newname > git rm oldname That's what I though but it's more like: git show :0:oldname > newname git add newname git rm --cached oldname mv oldname newname Basically, a move but also preserving staged/unstaged contents. But yes. How git handles renames can sometimes be a bit of a PITA. On Sun, Apr 23, 2023, 12:16 AM <rsbecker@xxxxxxxxxxxxx> wrote: > > $ git add file1 > $ commit -m "Commit 1" > $ git mv file1 file2 > $ git status > On branch master > Changes to be committed: > (use "git restore --staged <file>..." to unstage) > renamed: file1 -> file2 I think your point is better illustrated git add file1 commit -m "Commit 1" echo 'Changed' > file1 git mv file1 file2 git status Which yields: Changes to be committed: (use "git restore --staged <file>..." to unstage) renamed: file1 -> file2 Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: file2 Or perhaps even: echo Initial > file1 seq 1 10 >> file1 # We need a larger file to detect rename with change git add file1 git commit -m 'Commit 1' seq -i 's/Initial/Changed/' file1 git add file1 # Stage changes seq 11 20 >> file1 # Add some unstaged changes git mv file1 file2 This will result in a staged rename, as well as the staged change 'Initial' -> 'Changed' with a bunch of additional unstaged lines of numbers 11 to 20. NB that this doesn't play nice unless the contents of file1 in HEAD and index are similar enough (at least 50%?)
