If you squint hard enough, this is really a pretty similar idea to Polkit [0] but with a much simpler communication layer.

[0]: https://polkit.pages.freedesktop.org/polkit/

> All these named reset types could just be two separate reset commands, both pointing to a commit, one resetting the files on disk, one resetting the index.

It sounds to me like you want `git restore -W` and `git restore -S`.

For the compiler in particular, it's pretty common practice to depend on a recent version. The backward compatibility situation is generally excellent, so the only real challenge is getting the compiler installed. That's generally straightforward with rustup, and Debian/Ubuntu also package several versions (under different package names) that are more recent than the distro's default.

With the right workspace mapping, you can pull in just part of the depot, which makes the repo size a lot more manageable.

The Unison programming language is built around that idea: https://www.unison-lang.org/docs/the-big-idea/

BABLR is building that! It's entirely fair to say that BABLR takes Unison's approach and allows it to be used with every programming language.

YMMV, naturally, but I've found that some embedded devices have really excellent hardware abstraction layers in Rust that wrap the majority of the device's functionality in an effectively zero-overhead layer. Timers? GPIO? Serial protocols? Interrupts? It's all there.

- https://docs.rs/atsamd-hal/

- https://docs.rs/rp2040-hal/

> or that third type of schema whose name escapes me

RRELAX NG, perhaps?

Well, for one thing, classic Outlook's HTML rendering engine (to the extent it's even an "HTML" rendering engine instead of a Word document rendering engine) has some fairly radical divergences from standard HTML/CSS behavior. For those of us who have to generate HTML e-mail for whatever reason, it's distinctly unpleasant.

That might not be enough reason in and of itself to throw out the whole application, but I sure won't miss that one part of Outlook.

Well, older versions of Outlook actually used MSHTML/Trident as a render engine: the engine of Internet Explorer.

They could, if they want, use WebView2 - embedding MS Edge.

While I obviously don't know, I'd guess that they could plunk in Edge/Blink and call it Outlook 2025.

The file contents are logically distinct blobs. Packfiles will aggregate and delta-compress similar blobs, but that's all at a lower level than the logical model.

Is that relevant to something? The logical model is identical for every source control system. Deltas are a form of compression for storage in every source control system.

> The logical model is identical for every source control system.

Most source control systems have some common logical concepts (e.g. files and directories), but there's actually significant divergence between their logical models. For instance:

- Classic Perforce (as opposed to Perforce Streams) has a branching model that's very different from Git's; "branches" are basically just directories, and branching/merging is tracked on a per-file basis rather than a per-commit basis. It also tracks revisions by an incrementing ID rather than hashes. - Darcs and Pijul represent the history of a file as an unordered set of patches; a "branch" is basically just a set of patches to apply to the file's initial (empty) state.

All of that is above the physical state, which also differs:

- Perforce servers track files' revision histories in a directory hierarchy that mirrors the repository's file structure rather than building a pseudo-directory hierarchy over a flat object store. - Fossil stores everything in an SQLite database.

> Is that relevant to something?

Yes. You can use a VCS reasonably effectively if you understand its logical model but not its physical storage model. It doesn't work so well the other way around.

Especially with Vue 3, most of the reactive state management you need for all but the largest and most complex of apps is built right into the core. Vuex and Pinia really aren't necessary for most users.