[zeotroph]

Whoa, the line "Every save is uploaded, automatically [by default]" needs to qualify the non-default options. Can a company policy demand that? I hope there is a protocol-level, client-side opt-out for that, otherwise this VCS will work for the company first, and the dev is an afterthought.

"Upload every keystroke" is a huge no, and is going to be abused by companies looking for some performance metric to apply to devs (cloud IDEs are going to lead to that as well). Or things will revert to pre-git workflows where a huge number of files will remain open/changed until the final submit/push.

My workflow is to do the `grace checkpoint` equivalent and only make it public once it is presentable (and won't waste other peoples time when looking over or reviewing it). I never ever want these personal checkpoints/commits anywhere else. Mercurial/hg initially also had no easy way to have and clean up local-only commits, so for me and many others git it was.

[indymike]

> Whoa, the line "Every save is uploaded, automatically [by default]" needs to qualify the non-default options. Can a company policy demand that? I hope there is a protocol-level, client-side opt-out for that, otherwise this VCS will work for the company first, and the dev is an afterthought

I'm not so worried about the company. If they want every save uploaded, there are other ways to accomplish that, and they will have their upload. As a developer, I do not like "every save" saved because many editors trigger reformats on saves and such. Who cares about pre-reformatted code? That makes for junk history being pulled into VCS in a way that will eventually make the VCS data garbage. This is a feature that works for some workflows, but I suspect will be not so great for the team.

[thfuran]

I don't think that works for the company or the dev. It turns history into a giant steaming pile of garbage instead of a series of meaningful changes. History will be riddled with invalid state: Code that won't even compile, code that compiles but just had something important deleted without yet being replaced, etc.

[SBArbeit]

> History will be riddled with invalid state: Code that won't even compile, code that compiles but just had something important deleted without yet being replaced, etc.

No, it won't.

Saves are ephemeral; they're for your personal use to look back at the changes you've made recently, to enable a time-limited file-level undo, and to help you get back into flow after an interruption by being able to review what you were thinking and working on. Saves will be automatically deleted after a repository-level settable length of time, I'm thinking 7 days by default, but we'll see what makes sense.

Checkpoints are also ephemeral, they'll just have a longer life before getting deleted. They're for your reference, to help you keep track of your work, or keep track of an interesting version, or whatever you want to use them for. Or don't. Up to you. I don't imagine caring, for instance, what versions you checkpointed nine months ago.

This eliminates the "squash vs. no squash" debate. The only references that get to `main` are promotions. Nothing to squash.

All of this makes version control more ambient, more something that just happens in the background, effortlessly. Once you try it, it's really nice. Obviously, I've been the first beneficiary of it.

I wouldn't want to have to explicitly "push" changes to my OneDrive files, and in the same way, I don't want to have to explicitly "push" changes on my own branch anywhere, that should just work.

[robertlagrant]

> It turns history into a giant steaming pile of garbage

Do we know that? There are still commits.