possibly several parents, like 8 parents

Fun fact. Such merges with more than 2 parents are called 'octopus merges'. The Linux repo has a single merge with 66 parents that Torvalds named the 'Cthulhu merge'.

Git never deletes a commit that is less than 90 days old.

On its own, that is. Not if you do a git gc.

Deleting a branch removes a reference to a commit, but the commits in the branch are still there.

but you can see them using “reflog” related commands

Reflog - one of the most underrated git commands that has the potential to save your life some day. At least one team member must learn it.

What's ironic is that rebases aren't as hard as many consider it to be. Once you've done it a couple of times, you just do it everyday as easily as you commit changes.

I'm yet to hear anyone saying that chatGPT can navigate the complex series of design decisions needed to create a cohesive app (unless of course, it was trained on something exactly the same). Many people report spending an inordinate amount of time rectifying the mistakes these LLMs make. It sounds like a glorified autofill (I haven't used them yet). I shudder to think about the future of the software ecosystem if an entire generation is trained to rely entirely on them to create code.

I have a feeling that the OS in question here is Windows. Not as bad as Apple's walled garden, but similar results.

Until you start seeing its reviews. Or else, you should try using it for data you can afford to lose (unimportant or backed up) - which is what reviewers would be doing anyway.

I’m curious, what tools are you talking about?

My fav ones are b4 and lei - both backed by a system called public-inbox. Linux kernel Lore is a public-inbox instance. There are other tools too - like patchwork. B4 and Lei, for example make working with patch series a breeze. You can also do things like compare different versions of the same branch - something that Github PR model is sorely lacking in.

What is happening here? Where is the patch?

That's what public-inbox and patchwork are for. Lei is especially useful with public-inboxes. If you are a bit more established, there are tools like notmuch and aerc that can make it even more easier.

Is each email a commit?

Yes, that's the idea. But more specifically, each email is a patch. Usually, a single patch is a refined commit with a full feature that you get after proper rebasing to weed out experimental code, mistakes, etc. A single submission is often just one or a handful of patches.

Where at the comments on the patch?

You don't deal with patches and emails manually that deep. You only need to have a rough awareness of the location of the patches (lei, notmuch, etc help you with this awareness). Code review mails and discussion mails are often threaded and intertwined with a series of patches. Threading actually helps you to follow the correct flow of discussion. Think of mailing lists as PR, Issue tracker and discussion forum rolled into one. You wont be hunting patches in this haystack. That's the job of the tools - they extract the correct series of patches in the right order, ready to be applied. Some can even alert you to the presence of newer revisions of the patch series. (I'm not even sure how far this goes - I haven't tried patchwork yet). There is actually a lot of automation involved.

but mailinglists are even worse

Even if they decided to keep mailinglists, they could at least put on a better UI

Frankly, here is the problem! All the other problems you mentioned boils down to this. The thing is - Github and Mailing lists deal with the same kind of data - with the latter being more transparent. But the mailing list interfaces are god-damn awful. But honestly, it doesn't have to be like that. I believe that with some proper UI design, mailing lists can offer an experience that's at par or even better than GH PRs. All the noise and clutter you mentioned doesn't need to be there. The tools make all the difference. Webmail clients like Gmail just butcher the mails. But it's already much better when you have a text-only threaded mail client. I believe people hate email workflow just because of how badly its interface is designed.

I don't think it's practical for any distro to package every possible combination of cross building toolchains. Perhaps you should consider Crosstool-NG to get the toolchain you want.

All the companies that recently switched their products from open source licenses to non-free source-available licenses (like BSL and SSPL) were companies like this that offered hosted services. Their argument was that the big cloud companies were using their product to make money and causing them to lose business. Should we worry about a similar future for gitea?

It may be premature. But this is the gitea's second move in that direction, after transferring the project's control to a crypto-based for-profit company. Was Codeberg e.V (the nonprofit behind forgejo fork and Codeberg) justified in doubting gitea?

I too use Rust for what normal people use shell scripts for. But I have a feeling that Rust is falling into the same trap that other languages with similar easy dependency management fall into (Python and NPM are good examples). You end up with a dozen direct dependencies and hundreds of indirect ones with dozens of levels of hierarchy. C and C++ programs have fewer dependencies because each additional one adds more headache for the developer. Drew Devault's Hare language is giving language repo and package manager a skip for the same reasons. And I'm starting to think that he may have a point.

You don’t own anything if it’s hosted in the cloud.

Unless you own the cloud. Self hosting should be made as ubiquitous as linux distros.

Source available

That's why there should always be a gitignore file with everything that shouldn't get into the repo. At least in the case of open source projects, you can ask the contributor to clean up the commits. But one lazy developer is enough to cause headache for everyone in academic projects and work projects.

An equally important skill is the ability to create clean commit histories using interactive rebases or tools like stgit. Everyone complains about this being too complicated for regular developers. There is some truth to this too. However, the regular commit and forget workflow is an excuse for many lazy developers to slack off on the quality of commits.