I'll use a simple example, with one `main` branch and however many child branches, like most repos.
In Git, we merge to `main`. In effect, we take code from some other branch, and we shove it towards `main`, using a merge operation which sometimes results in code being created in `main` that's never existed in any other branch.
This seems... odd. Even if we're used to it, it's just weird. Why would we want something in `main` that's never existed anywhere else, that's never been on a developers machine before, that's never been tested locally? So we build CI/CD pipelines and automated testing to check that code that's never been seen anywhere else and hope it's good.
In Grace, changes move from `main` to the child branches through (auto-)rebase. There are no merges. The "merge" takes place during rebase, when changes from `main` are applied to the child branches.
A promotion in Grace takes an already-existing version that's been committed to a branch, and simply creates a new reference to that root directory version in `main` that doesn't change any code at all. It's a simple database insert, actually.
> Branch-level control of reference types
Oh, hell yes. This is a great feature, actually. When `main` only allows Promotions and Tags, you're guaranteed that nothing gets to it without a promotion, which we can expect we'll have proper authorization controls for, and proper event-driven pre-checks with CI/CD, etc.
No accidental "oops I pushed a secret and now everyone has to deal with rewriting history". Even if you push a secret to your branch, you can delete that save or checkpoint or even commit immediately. No harm, no foul. And the hosters will have something like GitHub's Secret Scanning to make sure that stuff doesn't end up in `main`.
> SignalR
Fortunately, you won't have to manage it. ;-) The hosters, like GitHub or GitLab, will manage it for you. Microsoft already has first-party services with hundreds of thousands of concurrent users on SignalR, I'm not worried about this at all.