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