Git-blame-someone-else

I assumed they were recording actions taken via the github UI and APIs, not the git commit log. If someone merges a pull request you opened, poof, you contributed the lines merged from that pull request regardless of the git author line. Same if you run `git push` with your github login credentials.

Apart from attributing things to the wrong person, git author line seems like it must also have the issue of not attributing things at all. What if I signed up with a different email address than I use for git?

You gain the ability to prove that a certain commit came from your machine or someone with full access to it, they don't.

To be honest, everyone should be signing their commits in a professional environment. It takes minutes of work to set up and greatly increases the trust you can have in the code base.

If you're scared of affecting your workflow, just don't protect the GPG keys with a password (dangerous) or use your operating system's trust store to unlock them at login (less dangerous, but still suboptimal).

I sign my work commits without ever entering a password in a prompt. Some of my coworkers also sign their commits, most of them don't.

https://i.imgur.com/TqbfZaP.png

Once you move on from just banal issues like whitespace and move your way up to actual structural concepts in the code, ad-hoc starts completely falling apart (at least in my experience.)

I once encountered someone who did a giant re-formatting of code by rewriting past commits. Pretty disruptive for a day but did manage to keep history in-tact. Also, a little (or a lot?) dangerous...

Git doesn't store what actually was changed. Git stores how to reconstruct the new file from the old file in a space efficient way.

This is unrelated to storage of who changed what, only "what is the minimal way to reproduce the end state from the beginning state".

As a result, tools like blame take the two versions and try to figure out what someone actually changed, trying to turn applesauce back into apples.

Whether it gets it right or not has an element of luck to it (the diff algorithms are also often based on finding the minimal sequence of edits.). Whether it happens depends on the algorithm and it's heuristics, and often whether there is a single unique minimal sequences that could produce your end state from your beginning state (if not, it's not actually possible to say what you changed with 100% accuracy)

git log -S instead is saying "give me all the times this line seems to have changed", and then you do the work of figuring out which were real and which are artifacts of the diff algorithm.

Even if they they did, once they change the history change, other developers working with the repo would be alerted of the remote branch changing out from under them next time they try to pull. And even if the change doesn't result in a conflict, and each of those other devs blindly accept the resulting merge, the original authors' commits will still be in the history resulting from the merge. So if those developers ever pushed anything, the original commits would be re-introduced.

Now, it could be abused if a single developer inherits a project that nobody else has checked out. But it's still a high risk strategy for the unscrupulous dev.