Fossil versus Git

If you can live your life without it, good. But if I want to use a GUI with links instead of markdown files in a repo from which I can't click to go to the next article, an ssg and a dependency on Github/Gitlab/whatever host I store my code in, and other tools, then fossil does it all for me right from a single binary that will be the same for everyone.

  plan $CURLOC "alice's restaurant"                \
  | dress-with pit-stops -every $(( RANGE - 100 )) \
  | drive

I've seen plenty of cars in which you have to bring your own radio. AFAIK, there's even a standard connector in the back of the hole where the radio fits (and the size and shape of the hole seems to always be the same, so it's probably standardized too). I've even seen things like DVD players which fit into that same hole (using an articulated screen which retracts into the device's body).

It depends. InnoDB, assuming the DYNAMIC row type, will store TEXT/BLOB on-page up until 40 bytes, at which point it gets sent off-page with a 20 byte pointer on-page. However, it comes with a potentially severe trade-off before MySQL 8.0.13: any queries with those columns that would generate a temporary table (CTEs, GROUP BY with a different ORDER BY predicate, most UNIONS, many more) can’t use in-memory temp tables and instead go to disk. Even after 8.0.13, if the size of the temp table exceeds a setting (default of 16 MiB), it spills to disk.

tl;dr - be very careful with MySQL if storing TEXT or BLOB, and don’t involve those columns in queries unless necessary.

Postgres, in comparison, uses BYTEA as a normal column that gets TOASTed (sent off-page in chunks) after a certain point (I think 2 KiB?), so while you might need to tune the column storage strategy for compression - depending on what you’re storing - it might be fine. There are some various size limits (1 GiB?) and row count limits for TOAST, though. The other option is with the Large Binary Object extension which requires its own syntax for storage and retrieval, but avoids most of the limitations mentioned.

Or, you know, chuck binary objects into object storage and store a pointer or URI in the DB.

I strongly disagree. I rebase feature branches on a daily basis and it's a must-have feature for anyone who works on feature branches that you want to keep updated and mergeable as fast-forward merges and ideally peel off small commits in separate pull requests.

Here's a small example of a very mundane workflow. I was assigned an issue where I needed to enable a component in a legacy project. I cut the feature branch and started going the "lean on the compiler" approach to fix blockers. Each individual blocker I addressed I saved as a local commit. Throughout the process I spotted a couple of bugs in mainline, which I also saved as local commits. Finally I got a working local build, but team members already merged a few updates onto mainline that created conflicts. I rebased my feature branch onto mainline's HEAD and fixed the conflicts in each local commit. Time to post pull requests for the fixes. I noticed a few of them were related so it would be preferable they went in before everything else. I did an interactive rebase to reorder local commits to move these bugfix commits to the start of the local branch. I squashed them, cleaned them up, and posted a pull request. The pull request was merged into mainline and in the meantime other PRs went in as well. I rebase the remaining commits in the local branch. Followed the same process for another bug. Rinse and repeat. Finally all I had left was the fix for the original issue. I rebased the remaining commits onto mainline, cleaned them up, and posted a PR. Done.

One ticket, around 3 PRs, and almost a 1:1 ratio of rebase-to-PR.

And here you are, saying rebasing doesn't bring any real value.

I think those who complain about rebase are overrepresented by the subset of Git users who barely go beyond the very basic features of checking out branches, pulling changes, and committing stuff. They have no idea how and why other features work, so they complain about things they know nothing about. When pressed about basic usecases, they fall back to trying to fill in the holes in their reasoning by arguing that workflows should be different or that other features are similar, while completely ignoring that features like rebase do the job and do the job very well and very easily.