From: Jeremy Morton Date: Mon, 24 Apr 2023 20:05:29 GMT Subject: Re: Proposal: tell git a file has been renamed Message-ID: In-Reply-To: But if you were doing, say, a git blame for a file, you'd be able to see the commits where its lines were actually last modified even through the rename, rather than a bunch of them being stopped at the "added this file (because it wasn't detected as a rename)" commit, no? -- Best regards, Jeremy Morton (Jez) On 24/04/2023 20:41, Junio C Hamano wrote: > Jeremy Morton writes: > >> The standard answer for this is to rename the file in one commit, then >> make the changes. > > Oh, by the way, this is a pure myth that would unlikely be helpful > in the bigger picture. > > When you rename and heavily modify the resulting new path because > you have to solve something, such a work would likely be done on the > same topic branch. One step of it may be a pure rename, and other > steps may involve heavily changing the renamed result, or you may > update the contents in the original and the do a rename at the end, > but either way, when you integrate the end result of the whole topic > branch into the master history, what such a merge will see is that > the original file has disappeared and a new file with contents not > at all similar to the disappeared file has appeared. "pure rename > with changes in separate commits" would have no effect when showing > such a history with "git log --first-parent -p" for a birds-eye > view. > >