> you might as well just use SVN

I've got a feeling you are not being fully serious, so on that assumption instead of me explaining why this really not at all the case, how about you provide an example of a workflow that you think crucially depends on merging rather than rebasing, and we can discuss that?

> Bisect works fine. Could you be more specific?

Sure: given a test command, show me a simple git bisect invocation that finds the merge commit that broke master.

> things that are released together should go in the same repo, while things with separate lifecycles should have their own repositories.

I think this is a useful criterion, but one that tends to be only clear-cut for things like shrinkwrapped software (and it's not the only thing that matters). If you run a service of any complexity and with any sort of uptime requirements, you will not ship everything together, even if its part of a single feature and often you will have different versions of the same service in production in parallel as well. Al

> if a project depends on a previous release of an internal library, it's misleading to have that internal library in the same repository as that project, because you'd see the "current" version rather than the code you were actually using

A strange objection. Surely the point of having a super-repo would be that the subrepos at any one commit in the super repo would form a consistent state of the world, rather than you pinning inconsistent versions of different repos in the same commit of your super-repo?

> I don't want to think about different parts of the checkout being on different revisions, branches, or tags

At the most basic level you could think about the sup-repos like a pinned (yarn, poetry, budler, ...) dependencies and the super-repo as a lockfile with extra benefits (such as 'git diff HEAD^' presumably showing you all the source changes in the sub repos since the last time you committed their versions in the super-repo). If you are not directly working on code in any of the sub repos, you simply don't have to care about their different revisions, branches or tags. If you do want to make a change in one of the subrepos with a view to landing this change in the super-repo as well, it is true that you will probably create a new branch in first the subrepo, have that merged and then create a branch in the super-repo that switches it to the new version. But presumably the reason you don't just have a mono-repo to start with is because there is some degree of indepdendence (such as your proprietary app depending on an open source lib you also maintain). One realistic example from the open source world might be something like OpenBSD which is (if I remember right, apologies if I got something wrong) developed in one big (csv?) mono repo and that also includes all the bits that have made it into the wider unix eco system like OpenSSH or libreSSL. The cross platform versions of these are developed out of stream by people periodically pulling the whole OpenBSD repo as canonical upstream, copying the relevant subset of stuff across, updating their compatibility layers and pushing it to separate repos that contain just OpenSSH (or whatever). Presumably depending on goals and priorities, having OpenSSH be a sub-repo instead would offer benefits to at least some of the people involved (assuming a well designed sub-repo mechanism).