Hacker News new | ask | show | jobs
by thfuran 768 days ago
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.
2 comments

> 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.

> It turns history into a giant steaming pile of garbage

Do we know that? There are still commits.