Maybe a number of my inquiries or concerns would be answered by me watching the video on the GitHub page and/or playing around the tool, but I'll yap here for now.
FWIW I appreciate a project of this scale using F# (not that the choice of language matters, it's just nice to see).
>The "merge" takes place during rebase, when changes from `main` are applied to the child branches.
This is just a difference in operation, but the problem you were alluding to in your previous sentence still exists in poorly trained teams.
Git has rebases. Grace has rebases. Neither solve the issue of "that's never existed anywhere else, that's never been on a developers machine before, that's never been tested locally."
>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.
This sounds like the equivalent of simply updating what commit a branch label is looking at in git (i.e., "fast-forward" is one of many ways this can happen as well as explicitly just changing what commit a branch is pointing to)?
>In Grace, changes move from `main` to the child branches through (auto-)rebase.
How do I revert or demote/"unpromote" a set of set of "grouped" changes that I no longer want on a branch? If it's a series of auto-rebases, do I have to define the set of changes I want to "revert" or demote?
If I have a rather complicated shared history between branches, can I "easily" query all the places a commit exists at and when it was promoted (or other actions related to it)?
>you're guaranteed that nothing gets to it without a promotion
The issue isn't gatekeeping things to a branch or repository -- we've solved that already. The issue is allowing and even encouraging an influx of complicated processes and subtle permission cascades that will likely mimic the company structure. Which is never a good thing since they are often not purposeful or well thought-out.
The Linux kernel project for example handles this by having authoritative repositories which is as wonderfully simple as it is strikingly effective (and sane). I've always used this model as well with orgs I've lead.
I have many other questions, but here's my rather ignorant or inexperienced take on some of the choices here. The good here is that "forcing" people to use rebase is absolutely the right thing to do IMO, it's the correct operation for 98% of VCS operations. The bad is that some of the design choices seem to echo what was done with SVN, CVS, Sourcesafe, TFS, etc.
Right or wrong the similarity or seemingly similarities with centralized VCS's of the past and the problems they implicitly have make me uneasy.
>Microsoft already has first-party services with hundreds of thousands of concurrent users on SignalR, I'm not worried about this at all.
I think we'll just agree to disagree here. I've used SignalR on and off since ~2014 (if memory serves correctly) and I've never had an amazing experience with it.