13 Matching Annotations
- Nov 2021
-
danallosso.substack.com danallosso.substack.com
-
I know a number of my subs and viewers are in India and I've noticed on Twitter and on Abhijit Chavda's channel that there's quite a bit of controversy about the way Indian History is taught to Indian students. That interests me a lot, but what I'm PARTICULARLY interested in is, how World History surveys throughout the world cover world history. If part of this involves continuing the narratives introduced by colonizers, like the Aryan Invasion myth, that's relevant to my question.
I've seen/heard several articles about Narendra Modi and the BJP rewriting history in India over the past several years.
Examples include:
- https://www.reuters.com/investigates/special-report/india-modi-culture/ 2018-03-06
- https://www.washingtonpost.com/news/worldviews/wp/2018/06/01/indias-new-textbooks-are-promoting-the-prime-ministers-favorite-policies-critics-allege/ 2018-06-01
- https://carnegieendowment.org/2019/11/16/bjp-has-been-effective-in-transmitting-its-version-of-indian-history-to-next-generation-of-learners-pub-80373 2019-11-16
-
- May 2021
-
syslog.ravelin.com syslog.ravelin.com
-
Preserving history; we often find ourselves using the git blame tool to discover why a certain change was made.
-
Preserving commit hashes; we use commit hashes in binary names and our issue tracker; ideally, these references remain intact.
-
-
stackoverflow.com stackoverflow.com
-
In case you want to put project-a into a subdirectory, you can use git-filter-repo (filter-branch is discouraged)
-
Note: This rewrites history;
-
-
stackoverflow.com stackoverflow.com
-
If you want the project's history to look as though all files have always been in the directory foo/bar, then you need to do a little surgery. Use git filter-branch with the "tree filter" to rewrite the commits so that anywhere foo/bar doesn't exist, it is created and all files are moved to it:
-
- Oct 2020
-
en.wikipedia.org en.wikipedia.org
-
A backronym, or bacronym, is an acronym that is assigned to a word that existed prior to the invention of the backronym.
-
- Jul 2020
-
lwn.net lwn.net
-
"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!
-
- May 2020
-
github.com github.com
-
# 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.
-
-
gitlab.com gitlab.com
-
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.
-