I know that Hitler was a bad guy. Really! But why detest everything he coopted? Many have a very different meaning in reality. 'Swastika' is Sanskrit for a symbol of peace and wellness. Similarly, the Aryans were an ancient race, whose lineage still exists in the world today among a huge population (I'm talking about genealogy, not the eugenics concept). I'm one of them. But we rarely discuss that - not because of the Nazi link, but because it hardly makes any difference today. (However, our language is still very similar to the Aryan language.) What we actually like is to explore other languages, cultures and traditions and absorb their best - something I hope we can all agree isn't very Nazi-like.

Oh! I misunderstood. Sorry! Glad to meet a fellow Gentoo here!

I don't think that either of them count as 'Linux distributions'. And sadly, it matters. Even the bugs are not consistent across distros.

The story behind git is very dramatic. You should read it.

That blame must go to github. Not Torvalds.

Another aha moment was learning that an easy way to squash commits is just to do a git reset followed by git commit -am “whatever”

You can do that in a single step instead with git commit -a --amend.

A big group of Apple fanbase are not ignorant, rather willing accomplices. Just look at the downvotes here. They will do anything to defend Apple's rogue behavior - like resorting to whataboutery, blaming the EU or even claiming that PWAs are bad.

My theory is that by defending Apple, they're trying to make themselves feel important with their overpriced products.

Diff is only a viewing option

It isn't. Git uses 3-way diff/merge algorithm quite liberally behind the scenes.

Nicely written! Going into my bookmarks.

SVN was, along with its proprietary contemporaries like Perforce, a pain in the ass as far as branching and merging and collaborative workflow across more that one branch of development or one machine installation.

I'm one of those who was unfortunate enough to use SVN. It was my first version control too. Committing takes forever - to fetch data from the server to see if the 'trunk' (the branch) was updated (I see why Torvalds hated it). Even committing caused conflicts sometimes. People also used to avoid branching, because merging back was hell! There was practically no merges that didn't end in merge conflicts. The biggest advance of merge workflow from those days was the introduction of 3-way merges. Practically all modern VCSs - including git and mercurial - use 3-way merge. 3-way merges cut down merge conflicts by a huge margin overnight. Git even uses 3-way merges even for seemingly unrelated tasks like revert, cherrypick, rebase, etc (and it works well for them. We barely even notice it!). Surprisingly though, 3-way merges were around since 1970s (the diff3 program). Why CVS and SVN didn't use it is beyond me.

Anyway, my next VCS was Bazaar. It's still around as Breezy. It is a distributed VCS like Git, but was more similar to SVN in its interface. It was fun - but I moved on to Mercurial before settling with Git. Honestly, Mercurial was the sweetest VCS I ever tried. Git interface really shows the fact that it is created by kernel developers for kernel developers (more on this later). Mercurial interface, on the other hand is well thought out and easy to figure out. This is surprising because both Git and Mercurial share a similar model of revisions. Mercurial was born a few days after Git. It even stood a chance for winning the race to become the dominant VCS. But Mercurial lost kernel developers' mindshare due to Python - it simply wasn't as fast as Git. Then GitHub happened and the rest is history.

And therefore, the version control system used by the team for one of the most advanced pieces of technology in the world for quite a lot of its development, was… diff and patch. And email

That sounds like a joke, but it actually made more sense than anything else they could do.

I was a relatively late adopter of Git. But the signs of what you say are still there in Git. Git is still unapologetically based on the idea of keeping versioned folders and patches. Git actually has a dual personality based on these! While it treats commits as a snapshot of history (similar to versioned folders), many operations are actually based on patches (3-way merges actually). That includes merging, rebase, revert, cherrypick, etc. There's no getting around this fact. IMHO, the lack of understanding of this fact is what makes Git confusing for beginners.

Perhaps this is no more apparent than in the case of quilt. Quilt is a software that is used to manage a 'stack of patches'. It gives you the ability to absorb changes to source code into a patch and apply or remove a set of patches. This is as close you can get to a VCS without being a VCS. Kernel devs still use quilt sometimes and exchange quilt patch stacks. Git even has a command for importing quilt patch stacks - git-quiltimport. There are even tools that integrate patch stacks into Git - like stgit. If you haven't tried it yet, you should. It's hard to predict if you'll like it. But if you do, it becomes a powerful tool in your arsenal. It's like rebase on steroids. (aside: This functionality is built into mercurial).

diff and patch and email could do that, and it was quick and easy for small changes and possible (with some discipline) even for large changes. Everyone sort of knew that it wasn’t ideal, but it was literally better than anything else available.

I recently got into packaging for Linux. Trust me - there's nothing as easy or convenient as dealing with patches. It's closer to plain vanilla files than any VCS ever was.

Some kernel developers were unhappy with having the source and all revisions “held hostage” within a proprietary VCS

As I understand, the biggest problem was that not everyone was given equal access. Most significantly, many developers didn't have access to the repo metadata. The metadata that was necessary to perform things like blame, bisect or even diffs.

As best I remember, things came to a head when a couple members of the former group actually had their licenses pulled because McVoy said they had broken the agreement by “reverse engineering” his protocols, with people disagreeing over whether what they’d done actually fit that description, and the whole thing blew up completely with people arguing and some people unable to work.

That sounds accurate. To add more context, it was Andrew Tridgell who 'reverse engineered' it. He became the target of Torvald's ire due to this. He did reveal his 'reverse engineering' later. He telnetted into the server and typed 'help'.

Linus, in his inimitable fashion, decided to solve the problem by putting his head down to create a solution and then dictatorially deciding that this was going to be the way going forward.

I thought I should mention Junio Hamano. He was probably the second biggest contributor to git back then. Torvalds practically handed over the development of git to him a few months after its inception. Hamano has been the lead maintainer ever since. There is one aspect of his leadership that I really like. Git by no means is a simple or easy tool. There has been ample criticisms of it. Yet, the git team has tried sincerely to address them without hostility. Some of the earlier warts were satisfactorily resolved in later versions (for example, restore and switch are way nicer than checkout).

This is objectively wrong! Git has 'request-pull' command that generates a message to an upstream maintainer to pull changes from an online downstream clone. That request message can be sent by email or some other means. But no patches are involved. And no - Github did not invent it. It was there before Github existed. In fact, there is a rant by Torvalds as to how GitHub reimplemented PRs poorly, throwing away good features of the request-pull command.

Apparently, this change was in 2016 - before MS bought them. However, I agree with your point. But the proof of that isn't in restricting search to logged in users. It's in how they ripped off FOSS code (esp GPL code) for training copilot. They did something that fundamentally damaged the roots of FOSS activity.

What indicates that Igalia doesn't want to make a browser with it? What else is their motivation?