Re: Proposal: tell git a file has been renamed
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Apr 24, 2023, 19:41 UTC
- Message-ID
- <xmqq8rehdq4m.fsf@gitster.g>
- In-Reply-To
- <8fe188a9-c01f-9fb5-5877-8ff508094b22@game-point.net>
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.