TechNom (nobody)

But calling that doff is misleading.

Git actually uses diffs behind the scenes a lot - 3-way diffs/merges to be more accurate. Merging, rebasing, cherry picking and even reverting are all 3-way diff-merges.

Mercurial took an interesting approach here. It stores commits as diffs with occasional snapshots in between. This is similar to how video codecs store frames as deltas with occasional full ‘keyframes’ in between. This is the way Mercurial blunts the diff-replay problem you mentioned.

Git AFAIK, stores each file modification as full snapshot, until it is packed at some stage. Mercurial doesn’t need this work around. Mercurial diffs are also format-neutral. It works fine with binary data.

Git is a lot of things at once:

1. A tool to record development history - warts and all
2. A tool to create a logical sequence of changes
3. A tool to communicate intent and ideas to a maintainer

Meaningless messages like minor and . don’t suit any of these roles - not even 1. Even when recording development history with all mistakes, you’d still need context when you look back at the history. Matklad is a well respected developer. I wonder why he’s make such a bizarre claim.

You might want to have a relook at your own statement here. It’s got a load of paranoia. Paranoia beyond common sense and realistic threat assessment is unhealthy.

As for the NSA, it’s like they have a split personality (which I think is true for anyone in their position). Their job isn’t all about stealing information. They also have the mandate to secure their own and their allies’ assets. After all, who knows what’s more vulnerable to thievery than an experienced thief? Their job is as much to harden security as it is to compromise.

Finally, their statement is to move to a safe language - one of which is Rust. For your apprehensions about their backdoors to be true, they’d have to compromise every memory safe language out there - Rust, Go, Swift, Nim… There’s reason to be suspicious if they recommend only one language (that is more or less what happened with the NIST pseudorandom generator algorithm). But that isn’t the case here.

And you need to assess statements on their own merit - not based on who says it. What they say is true even in our personal experiences. It’s been shown statistically that people write much fewer bugs (memory safety bugs are a huge class) with safe languages. I’m not even confident of writing correct C programs these days. Honestly, if your paranoia is true, then it’s easier for the NSA to recommend everyone to write in C or C++. That way people will write careless mistakes that they can exploit. And C/C++ usage is way more than for Rust or anything else. They’d target C/C++ compilers and standards to increase their impact.

It could in theory, be a faster way to checkout a different branch. Switching branches is a lengthy operation that involves a lot of deletions and replacements in the working tree. A fuse mount would simply be a rendering of the tree object. It doesn’t need to do anything until something is accessed. Even then, it would simply be a rendered view of a blob in the repository.

I don’t think you mean ‘merge’ - that’s a specific operation. I think you mean ‘squash’, which combines multiple commits into one. ‘Fixup’ is also something similar.

Git allows you to edit history in any way you like. The hardest is probably splitting a commit into multiple smaller ones. It requires you to edit a commit by resetting the HEAD and making multiple smaller commits before continuing with the rebase. Though it sounds complicated, it becomes easy enough after you try it a couple of times. You should check out git-rebase.io - a site dedicated to editing git history. You can learn to craft proper commits of high quality.

Once you get familiar with rebasing, you could try out stacked git. Interactive rebasing looks weak in comparison to what stgit can do. Stgit allows you to edit history like rebase. But that’s the least of it. It allows you to create proper commits from the start, rather than by editing at the end. In some ways, stgit gives you multiple staging areas - giving you incredible flexibility.

I use both separately. But the Linux kernel developers seem to use both together. I don’t know what criteria they use for each.

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?

The realization that Windows was stealthily making dozens of internet connections. I don’t know what they were for and there was no reasonable way to disable it.

I’m an evangelist so far as to recommend people to switch to Linux or BSD. But people always find some reason to stay on Windows - "I will switch when Linux starts doing ". (Not gaming). It often feels like they’re searching for a problem to justify not switching. I don’t bother fighting with such people.

I’m obsessed with modifying Linux to my liking. Programming was another one of my reasons for switching. These days, I program components of my desktop to suit my needs.

Facebook for all its nastiness was very much incompetent in influencing the direction of the web. Look at their failed attempts like free basics.

Google on the other hand has the web tightly in its dirty grip. At this point, they aren’t even pretending to be nice. Even those plans that cause them reputational damage are brought back in some other name.

The only way to stop Google is for the regulatory agencies to put their foot down hard. They should be divided into at least a couple dozen companies that are not allowed to do business with each other.