On Saturday, April 22, 2023 3:54 PM, Jeremy Morton wrote: >Subject: Re: Proposal: tell git a file has been renamed > >https://stackoverflow.com/a/1094392/178757 > >says: > >git mv oldname newname > >is just shorthand for: > >mv oldname newname >git add newname >git rm oldname The above stackoverflow topic is from 2009. A lot has changed since then. My test follows. Please note the status and git log contents indicating the rename. $ mkdir test2 $ cd test2 $ git init $ echo "Initial" > file1 $ 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 $ git commit -m "Rename" $ git log --patch commit 014068fcedaf361f45c356046cf513b79537f53f (HEAD -> master) Author: Randall S. Becker <rsbecker@xxxxxxxxxxxxx> Date: Sat Apr 22 18:02:07 2023 -0400 Rename diff --git a/file1 b/file2 similarity index 100% rename from file1 rename to file2 commit 235a33801b82eac67e25c57e512ca428f2d49cea Author: Randall S. Becker <rsbecker@xxxxxxxxxxxxx> Date: Sat Apr 22 18:01:48 2023 -0400 Commit 1 diff --git a/file1 b/file1 new file mode 100644 index 0000000..a77fa51 --- /dev/null +++ b/file1 @@ -0,0 +1 @@ +Initial > >On 22/04/2023 20:47, rsbecker@xxxxxxxxxxxxx wrote: >> No, history is preserved in the rename. >> >>> -----Original Message----- >>> From: Jeremy Morton <admin@xxxxxxxxxxxxxx> >>> Sent: Saturday, April 22, 2023 3:45 PM >>> To: rsbecker@xxxxxxxxxxxxx; git@xxxxxxxxxxxxxxx >>> Subject: Re: Proposal: tell git a file has been renamed >>> >>> I read that git mv is basically the equivalent to deleting the old >>> file, creating the new file, and adding the changes. Isn't it? If >>> so it's gonna have the same problem as I have now. >>> >>> -- >>> Best regards, >>> Jeremy Morton (Jez) >>> >>> On 22/04/2023 19:54, rsbecker@xxxxxxxxxxxxx wrote: >>>> On Saturday, April 22, 2023 2:02 PM, Jeremy Morton wrote: >>>>> Yes, I know Linus specifically doesn't store file rename info in Git. >>>>> The trouble is, every now and then, I'll come across a situation >>>>> where Git doesn't successfully detect that I've renamed a file >>>>> because I'm doing something like renaming a class at the same time. >>>>> So I'll have a file OldClassNameTests.cs and a NewClassNameTests.cs >>>>> but a bunch of lines in that file have also changed from >>>>> OldClassName.DoThing() to NewClassName.DoThing(). I can clearly >>>>> see that this is a rename, but Git sees enough changed content that >>>>> it doesn't realize it, and puts it in as a delete/add, losing the content history. >>>>> >>>>> The standard answer for this is to rename the file in one commit, >>>>> then make the changes. That's fine if you know ahead of time >>>>> you'll want to do this. However it's a total PITA if you have a >>>>> bunch of changes and you realize that a rename has caused this >>>>> problem. You now have to back out your changes to the renamed >>>>> file, add the rename, commit >>> it, then re-apply the changes. >>>>> >>>>> Could a command be added to git that means you tell Git that counts >>>>> as a file rename? Git would add a marker to the staging area that >>>>> the file has been renamed, and upon commit, would first generate an >>>>> additional commit for each rename before generating the main >>>>> commit, ensuring the rename operation counts as an actual rename, >>>>> and the content's >>> history is maintained. >>>> >>>> Would git mv work in your situation? You can stage changes to the >>>> original file, >>> then use git mv. Or use git mv first. The rename shows as staged in any event. >>>> --Randall >>>> >>>> >> >>
