git still has issues with lots of files. I downloaded the sec Edgar database as files and I thought it would be nice way to store and watch changes.

Nope.

So slow. It does not like millions of files. And all my tooling that does a “quick” git status locked up the terminal, vs code, etc.

Did you try the file system daemon (git fsmonitor--daemon start) that’s built into git that was designed to speed up git status on many files?

> its inability to handle large repositories meaningfully

Out of curiousity, what other SCM tools can pull this off better?

I haven’t played with many because I simply don’t have the time between work (Google’s Piper and Git) and kids. Piper handles the monorepo by only offering files when requested by the file system at the specified commit (this is probably a gross or even incorrect simplification, but is how it presents to the user).

There are good reasons that one should keep the whole commit history to distribute a source of truth, but at the same time if one is going to place full trust in something like GitHub (as many do), there’s no reason that full trust can’t be given to a similar website that provides a Piper model with some mechanism to request more than one commit to be brought to local storage (to get more sources of truth).

End of the day, a large repo checkout is going to be limited by either your network, your CPU/storage to perform archive expansions, or frequently both. I get the impression that Android and Chromium are expanding faster than those other things are improving, but have no data to back that up.

Almost every big game studio uses Perforce

I think it's definitely possible to create a better CLI than git, however I think the majority of what unhappy users of git are imagining when they ask for a better UI would oversimplify things and end up removing a lot of valuable capabilities. These capabilities may not be suitable for a non-technical audience, but I believe should be table stakes for professional software developers as they are very sharp tools for managing the software development lifecycle that transcend specific languages or domains one may be working in.

To take your example of moving commits between branches, the git rebase parameters and --onto flag are definitely confusing, but each of them is clear and necessary when understood. The CLI could be refactored to be clearer, but the hard part is understanding what each one means, which you would need to do anyway even with a better CLI. Obviously one can work around these knowledge gaps, but once you understand them they are useful for an entire career and the warts tend to fade in importance relative to the value of a tool with the insane power-to-weight and rock solid architectural tradeoffs of git.

There is a major misconception that you move your "commit" around. Actually, each commit in the git history refer to a specific directory state and parent of such commit. You can't meaningfully "move" a commit directly. What the cherrypick and rebase does is.

1. The client diff content of your commit with previous one. 2. Apply such diff on content of another commit. 3. Create a new commit with the old commit message/author of commit in step 1.

And that is also what make git work for everyone, because it is simply a directory that contains tons of new_new_updated_project on steroids. It's up to you to decide what to do with it.

> arcane CLI commands

Are the syntax of the commands the issue or are all CLI commands arcane to you? What would you propose to be the command syntax if you were designing it?