Mike Gerwitz writes about free software, Git and software freedom, and also maintains the GNU ease.js library.
HN links his Git horror story as a guide to repository integrity and trust through signed commits, though one commenter raises issues with PGP signing.
> Before 2007, the way to participate in Open Source was fragmented. Each project had their own workflow, patches circulated in emails, issues were reported in a myriad ways, and if anyone wanted to contribute they had to figure out every project's rules.
And it was much better IMO. Now we have a centralized website, in the hands of a single corporation, which requires nonfree JavaScript for much of the basic functionality[1]. Git was designed to work well with email and has commands built-in to format, send and apply patches. I think anyone who used email for patches seriously will agree that they are largely superior to GitHub's pull requests.
The free software movement being fragmented is a good thing. GitHub is the land of trends: web developers using Mac OS X who make apps with the latest trendy frameworks like React and Angular (if you think that's a misportrayal, look at the first three pages of the most starred repositories on GitHub[2]). These people don't care about the free software movement, they're just following the current trends, one of which is "Open Source". But if they really cared about free software, they would not be using Mac OS X or GitHub, which requires you to run nonfree JavaScript code in your browser to report issues, open pull requests, etc.
The serious projects that do care about free software don't use GitHub.
[1]: See Mike Gerwitz's GitHub Does Not Value Software Freedom: https://mikegerwitz.com/about/githubbub
[2]:…
Git's hashes were not always verified all that often in the past (at least, as of 1.7.4.1):
http://stackoverflow.com/questions/5585388/which-git-commands-perform-integrity-checks
You'll see plenty of operations do not check the sha1, and will happily hand you bad data, including checkout and clone, depending on circumstances.
I haven't checked on the latest version, but at least previously, you'd have to run around using git fsck specifically to get it to notice some sha1 mismatches.
So at least trivially, the idea that "it uses sha-1 so it's safe" is silly even without considering the implementation, because it doesn't always check the sha-1 :)
(I'm not even going to argue it should, just pointing out it didn't)
You can also GPG sign git commits (see http://mikegerwitz.com/papers/git-horror-story.html for a long explanation of what does and does not get checked)
I was amused, after discovering Monotone through the I2P project that you can sign your commits in git too (although in a SCM not written in C++, look around for that famous Linus rant). I was well on board with the idea, like signing my many emails, but even as a rank amateur I have nightmares of waking up like this guy.
https://mikegerwitz.com/papers/git-horror-story
So I would love tarballs and other things signed, and I do not want to be one of those whiny moochers, but imagine the backlash you get as thankless free software developer when you bork your tag sign or mess up one commit and people through you under the bus, because you cryptographically agreed to it? Haha.
Those interested in how prototypes and classical inheritance relate (and don't) may be interested in work I did on GNU ease.js, which works with ECMAScript 3+. I have since extended it to support Scala-like traits.
https://www.gnu.org/software/easejs/manual/easejs.html#Implementation-Details
I also wrote a paper on some of the concepts:
https://mikegerwitz.com/papers/coope/coope.pdf
The `class' keyword in JS still leaves much to be desired; it's just syntatic sugar around the prototype model. There's nothing wrong with that model---it's just important to understand how it differs from what OOP developers traditionally expect.
To be honest even PGP signing has some issues: it's not clear what does it mean to sign a commit and there is plenty of misuse of that (see [0], `git push --signed` solves some of these issues).
Git patch workflow doesn't support signed commits and some kernel devs explore alternative ways of signing [1].
[0]: https://mikegerwitz.com/2012/05/a-git-horror-story-repository-integrity-with-signed-commits
[1]: https://people.kernel.org/monsieuricon/introducing-b4-and-patch-attestation
By "keybase providing alternative" do you mean that they have hosted, encrypted git repos?
You are wrong in so many ways. First of all, you are confusing "Microsoft bringing GNU to Windows" with "this is the first time GNU is brought to Windows." Then you go on to make it seem like if the GNU/Linux debate is just the craziness of some guy called RMS: wrong, many people support this distinction. Then you go off-topic talking about why GNU hurd is a mess. None of this contributes to the key topic here: Microsoft only brought GNU, not Linux and not Ubuntu. A topic where you were wrong again. Please read https://mikegerwitz.com/2016/04/GNU-kWindows