- Jul 2020
"that text has been removed from the official version on the Apache site." This itself is also not good. If you post "official" records but then quietly edit them over time, I have no choice but to assume bad faith in all the records I'm shown by you. Why should I believe anything Apache board members claim was "minuted" but which in fact it turns out they might have just edited into their records days, weeks or years later? One of the things I particularly watch for in modern news media (where no physical artefact captures whatever "mistakes" are published as once happened with newspapers) is whether when they inevitably correct a mistake they _acknowledge_ that or they instead just silently change things.
If the reality is you pushed out a release that doesn't even compile, and then you spotted the typo six minutes later, that's fine, that's what the git repo should show. Don't come to me asking if there's a way to change history so that it seems as if it didn't happen that way. How does that help anybody?
To answer your question:
How does that help anybody?
It keeps the history clean.
Assuming they push up an amended commit minutes after the bad commit, this shouldn't cause too much of a problem. (Depends how many people are working on it and how often they git pull.)
How does it help anyone to keep 2 separate commits that, semantically, could and should have been just 1? How does it help anyone to have a permanent record of someone's mistake?
If it can be easily and quickly fixed, I say go for it!
- hard to recover from earlier loss of trust/mindshare
- silently updating a published document
- rewriting history
- git: rewriting history
- how do we know a document hasn't been edited since the listed publication date?
- May 2020
# Two commits are considered the same if they have the same tree and # the same commit and author metadata. This is how we re-identify # commits after their hash IDs have been rewritten.
What I think we're lacking is proper tooling, or at least the knowledge of it. I don't know what most people use to write Git commits, but concepts like interactive staging, rebasing, squashing, and fixup commits are very daunting with Git on the CLI, unless you know really well what you're doing. We should do a better job at learning people how to use tools like Git Tower (to give just one example) to rewrite Git history, and to produce nice Git commits.