A lot of current GNU/Linux complexity have no benefits for most users and may be an hindrance when they want to slightly alter their use cases.

  sudo -> doas
  systemd -> rcctl
  nftable -> pf
  iproute2|netplan -> ifconfig|route
  alsa|pulseaudio|pipewire -> sndiod
  cgroups|podman|lxc -> jails(freebsd)*

* Openbsd does not like containers or being a vm host

A lot of BSD utilities that are not POSIX has really close interaction with the kernel. OpenBSD’s *ctl binaries are often the user-facing part of some OS subsystem. Linux subsystem often expose a very complex internal that you need to use some other project to tame down

Also I wouldn’t make hardware support an OS quality metric. Linux get by with NDA and with direct contributions from the vendors. Which is something the BSDs don’t want/don’t benefit from.

The best resource to check support is https://dmesgd.nycbug.org/dmesgd

But I use magit and I can commit specific lines and hunks as easily as files. That helps with managing changes to meaningfully group them.

If you remove the rainbow specification, it should be

  git log --graph --pretty=format:'%h -%d %s (%cr) <%an>' --abbrev-commit --

Because `checkout` is for getting the working directory to the state of a specific revision. Which both means switching branches (which are just pointer to revisions) and clearing changes (and get back to the starting revision). In both cases, you "check out" the version of the file at a specific commit or HEAD.

There can be experiment on the side that warrants your approach, but the amounts of merge going back and forth would make this hard to investigate (especially when blaming) I would prefer to have one single commit with a message that describe every contribution.

Maybe I wasn’t clear. What I wanted to convey is that the use of programming languages, paradigms, patterns, and other software engineering principles is related to the human side of programming.

You can solve a problem correctly, but with the resulting code being hard to parse. Or you can write readable code but with bugs. And almost everyone prefers the latter.

So badly written means incomprehensible code, mostly due to the size of it in the case of Agents. It’s all right if no one cares about the code. But if you expect someone to review it, changeset that even the author don’t understand is slop.

Also I can understand not squashing if the contribution comes from outside the organization. But in that case, I would expect a cleaned up history. But if every contribution is from members of the team, who can merge their own PR, squash merge is an easy way to get a clean history. Especially when most PR should be a single commit.

The compromise is worth it in traditional coding, because someone will care about the implementation. The test cases are more like the canary in the coal mine. A failure warrants investigations but an all green is not a guarantee of success.