All of the squash vs. no squash debate, which may or may not influence the way you use `git commit`, is a workaround - that we've forgotten is a workaround - for the fact that Git has only one way to say it.
Another way to say that: one of Git's leaky abstractions - the "commit" - forces us to use workarounds to make sense of it and how it's used and where it should be tracked and shouldn't be tracked.
Grace just decomposes those separate use cases into their own gestures to make it easier for you to track your own work in your own branch. If you want to see all of the references in your branch, `grace refs`. If you only want to see the checkpoints and commits - i.e. you want to see the versions that you explicitly marked as interesting for one reason or another, you have `grace checkpoints` and `grace commits`.
Promotions are what Grace uses instead of merges to move code from a child branch to a parent branch. We sometimes call merges "commits" in Git, and, again, leaky abstraction and overloaded term.
> so I think most git users will just get the impression that grace imposes a particular workflow and forces the user to perform extra administrative tasks
A short intro to Grace - like 15 minutes - will change that impression, I hope. Most of Grace's workflow will be the same as Git, some of it will be different, and that's OK. New tools bring new ways of working, and that's a good thing, especially when looking at Git's UX.
Do they, though? I mean, most users simply use a GUI layer on top of Git, and thus often are oblivious to what Git is doing under the hood.
> All of the squash vs. no squash debate, which may or may not influence the way you use `git commit`, is a workaround - that we've forgotten is a workaround - for the fact that Git has only one way to say it.
No, not really. At best it's a debate over which branching strategy a team wants to standardize over.
I happen to be working in a team which after months of doing non-ff merges of PRs it's starting to favor squash merges, and there is absolutely no discussion over the topic. Everything boiled down to "the history looks noisy, let's squash to remove noise as GitHub still tracks feature branches", followed by "sure, why not? If this doesn't work out we can fall back to non-ff". Done.
You abuse the term leaky abstraction here. That isn’t a leaky abstraction as a merge commit is literally a commit, isn’t it?