Post #1813012

2026-04-30 12:28 UTC

Huh. I have never in my 19 year career using git, ever wanted to copy a file and pretend all of the history of that file is also the history of the new file. I mean, I don’t think I’ve ever even wanted to copy a file? Why are you copying a file? Like, maybe I’m just too familiar with git to see the forest for the trees, but what the heck are you doing over there? 😅 And just in case it’s useful, a tip is that you can use git blame -C to have the blame algorithm use a heuristic to try and find a “source” line if it was moved, including from another file, during a commit, and then continue following the history of that line, to try and get the real commit where this was written, not just the last time it was moved around.

Replies (2)

@_stranger_@lemmy.world 2026-04-30 13:17

I can come up with some contrived examples. Maybe someone screwed up the history and they’re trying to repair it such that no one needs to worry about a rebase on their next pull? “compliance”/legal/cya reasons? I also wish to know!

Open ##1813076
@JATothrim_v2@programming.dev 2026-04-30 16:47

Why are you copying a file? I’m splitting a several thousand LOC file, which I don’t have previous history in. Like, maybe I’m just too familiar with git to see the forest for the trees, but what the heck are you doing over there? Normally copying a file and committing transfers the authorship to you, because the copy just appears from nothing as a brand new file, never known to git. This would prevent browsing the per-line “who changed this last” history past the copy and obfuscate who wrote what and when. (why the downvote?)

Open ##1814299