These are reasons enough. I switched to Asahi recently on my Macbook Pro M1

My fingerprint reader doesn't work, nor does my speaker. But hey, its way better than having to use MacOS. Atleast, linux lets me use my computer the way I want.

FIY speakers should work on a Macbook Pro M1 running Asahi. They have been working for a long time now (like 1 or 2 years) and they do work fine for me (running Asahi Alarm, not Fedora, but Fedora is supposed to work better since it's officially supported).

"Should work" is fine but, in my machine (2020 Macbook Pro M1 running Asashi Fedora Remix) it "doesn't work".

Microphone does though!

Just curious... Would Asahi Linux allow me to run llama.cpp on my m1? I have a spare laptop with lots of memory, wondering whether performance could be improved by using Asahi over running models on macOS?

totally agree here. commits are not for saving "your-current-work". Its about marking a definite step of change in the realm of the project itself.

making commits atomic is harder because we tend to just write code, without first breaking up the requirement into atomic pieces

Commits are for saving your current work. Commit early, commit often. Just clean them up when you're done!

Don't push half-baked work on other people! You waste their compute cycles needlessly, from now until the end of time.

I sometimes wish git supported hierarchical commits.

I.e., git can retain two representations of a sequence of commits: the original sequence, and also a larger commit that (a) produces the exact same code change as the sequence, and (b) has its own commit message.

Isn't that what a branch and a merge commit do?

Yep, as long as you use "--no-ff" to force a merge commit (and presumably edit the merge commit message instead of just using the default).

For viewing history you can use "git log --first-parent" to view only those merge commits, which should satisfy the people who love a linear history, without actually losing the intermediate commits.

I have entertained similar thoughts, but then on the other hand people already, and with some righteousness, criticize git for being too complex. It also requires careful assessment where the wormhole ends, how many levels of grouped commits should exist.

Then I remember that I have enough trouble getting a few dozen people together to write well formed and understandable commit messages for one level of commit messages alone. This scheme would require people to extend more energy on constructing commits which is at best something very few care about.

Then there are tickets and other corresponding information, but they could rot for all I care, as they so often do, unless a decent commit log is in place.

FWIW, Mercurial has this, and calls it changeset evolution:

https://www.mercurial-scm.org/doc/evolution/

the emerson quote just hits so hard and true