3 ms·

> How does it handle merge conflicts? I'll use a simple example, with one `main` branch and however many child branches, like most repos. In Git, we merge to

> How does it handle merge conflicts? 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.

whoknowsidont 2y ago
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.

whoknowsidont 2y ago

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.