I'm not a copyright-lawyer, but I think there are implications on who has authored the code, so preserving this detail can be important. The fancy copy reduced my blame by +90% on the final result.
git blame output can be affected by e.g. ignoring white-space changes.
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?)
Additionally, A update can ship a new stock version of a config that has fancy new options and some deleted ones, and your modifications to it in /etc can conflict.
Arch can either backup your version as .pacsave or install the updated file as .pacnew. It's your task to merge your modifications to the updated configs, and these files can slowly pile-up over time until something breaks.
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. :(
I have lately jokingly guessed when I see the particular style and confusion: it's you isn't it? And so far I have been right. The particular author's magic has expired, and I see the same fault replicated everywhere he has been.