Re: Proposal: tell git a file has been renamed

From: Jeremy Morton <admin@game-point.net>
Date: Apr 24, 2023, 20:05 UTC
Message-ID: <f5d21df1-2f52-8d19-4d2d-fa25ce9efbdc@game-point.net>
In-Reply-To: <xmqq8rehdq4m.fsf@gitster.g>

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 <admin@game-point.net> 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.
> 
>