If you try to "help" by taking control, you'll soon find that all the similar tasks are delegated to you and no learning takes place at all. So your only option is to just watch them fail and bear suffering.

Every technology invented is a dual edge sword. Other edge propulses deluge of misinformation, llm hallucinations, brain washing of the masses, and exploit exploit for profit. The better side advances progress in science, well being, availbility of useful knowledge. Like the nuclerbomb, LLM “ai” is currenty in its infancy and is used as a weapon, there is a literal race to who makes the “biggest best” fkn “AI” to dominate the world. Eventually, the over optimistic buble bursts and reality of the flaws and risks will kick in. (Hopefully…)

I posted this 9 months ago, and we are now at somewhere "brain washing of the masses, and exploit exploit for profit".

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.

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. :(

~~demons~~ ahem. data-races.

For immutable types it is the same though.

The most twisted thing I learned is that all ints below a fixed limit share the same id() result, so

>>> x = 1
>>> id(x)
135993914337648
>>> y = 1
>>> id(y)
135993914337648

But then suddenly:

>>> x = 1000000
>>> id(x)
135993893250992
>>> y = 1000000
>>> id(y)
135993893251056

Using id() as a key in dict() may get you into trouble.