Replicating git history for a file takes 1 merge commit and 3 commits, and this is propably one of the most complex workflows I have encountered:
(might not be correct...)
git checkout -b work
git mv file file.tmp
git commit
git checkout -b copy HEAD^
git mv file file2
git commit
git checkout work # can be skipped if you merge "work" instead.
git mergecopy # "work" and "copy" must conflict, stage file.tmp and file2 andcommit the result.
git mv file.tmp file
git commit<git blame is identical for file and file2>
I would love to squash this into a single commit, but git doesn’t have a copy operation or detection. :(
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.
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.
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!
Replicating git history for a file takes 1 merge commit and 3 commits, and this is propably one of the most complex workflows I have encountered:
(might not be correct...) git checkout -b work git mv file file.tmp git commit git checkout -b copy HEAD^ git mv file file2 git commit git checkout work # can be skipped if you merge "work" instead. git merge copy # "work" and "copy" must conflict, stage file.tmp and file2 and commit the result. git mv file.tmp file git commit <git blame is identical for file and file2>I would love to squash this into a single commit, but git doesn’t have a copy operation or detection. :(
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 -Cto 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.I’m splitting a several thousand LOC file, which I don’t have previous history in.
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?)
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!