From: D. Ben Knoble <ben.knoble@gmail.com>
Date: Thu, 20 Nov 2025 22:10:48 GMT
Subject: Re: Feature request: git cp
Message-ID: <CALnO6CDpBpRdbpXy26v5ug5n5opqzn-Uos+Qr=jx9mA-5wR9Ag@mail.gmail.com>
In-Reply-To: <CAL4-wQpeYc8-FfcZGWcs6KmR-oswTs3Kjcc7xAb34cFX7s0c-A@mail.gmail.com>

On Thu, Nov 20, 2025 at 4:24 PM Martin Guy <martinwguy@gmail.com> wrote:
>
> Thanks, but that only seems to affect "git log" retroactively, whereas
> I'm interested in it being part of the history so that "git blame"
> knows about it. At present, the blame for a line would end at the time
> of the split (when the file appears to have been created ex novo)
> though I suppose people would end up at that break and could then
> switch to tracking the old file instead.
>
> Maybe I'm expecting too much of git, with all the truly wonderful
> things it does already, but the idea seems to fit into the current
> scheme of things as seen from the outside (I don't know how the "git
> mv" line-based trackback works).
>
>     M
>

Please avoid top-posting ;)

"git mv" doesn't track the movement; Git reconstructs it post-hoc. See
[1]; while the tone obviously leaves a lot to be desired, the
technical rationale has stuck.

[1]: https://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org/


-- 
D. Ben Knoble