I got used to real-time version tracking when I was working on a book. The publisher insisted that the working files are kept in the Box folder (like a DropBox, or any other cloud-shmoud synchronized storage). This was... convenient and practical. This way of working is much better than the Git way if you work alone and produce dozens or hundreds of meaningful changes a day.
But at some point you have to publish. You have to make sure your state is correct to some level of certainty, and share it with other people. So you still need some kind of 'commit' thingie.
I think, Grace gets this both ways right. Personally, I just keep GitHub repos in a DropBox folder, but if Grace catches on, I might consider hoping in.
Thank you. One of the original, first-night-dreaming-about-it inspirations for Grace was the OneDrive sync client; since they rewrote it back in like 2018 or whatever it's been so rock-solid, and it's ambient.
I wanted that experience for version control; make as much happen in the background as possible, and make it fast when you need to interact with it.
OneDrive sync and "rock-solid" in the same sentence? I beg to differ.
Frequent conflicts due to non-synced files, the client crashing, randomly failing auth, files that are indicated to be recent and in sync but really aren't, no proper debuggability, no insight into why things don't work if they (frequently) don't. I could go on. OneDrive is a very bad thing to reference in this context.
That hasn't been my experience for at least six years. I think I've had one weird sync issue with OneDrive, like a couple of years ago... I forget, but it just works, across all of my computers, in near-real-time.
I think probably the big difference is "if you work alone". You have to go to extra effort with Git because you need your changes to be understandable and usable by other people.
I dunno if this is the right thing for team based coding projects. I think we just need something like Git with:
* A saner CLI
* Proper support for large files
* Proper support for submodules
* Better conflict resolution
I think Pijul goes some way towards some of those, especially the last one, and maybe submodules.
I am also hopeful for Pijul. But yes, the "if you work alone" backfires for it too. If I work alone, I can adopt Pijul in my work easily, but I don't really want it. If I work within a group then I do want a better VCS, but I should convince the majority of people I work with to switch to the new thing, so essentially I can't switch to Pijul unless there is an undoubtfully good reason to do so. And incremental gains are not a good reason. A "saner" and "better" isn't enough.
On the other hand, we all work alone in between commits (in a broad sense of the term), so having a second tier of a version control, a personal tier, may be a gamechanger.
There have been lots of projects over the last 10+ years that have been riffs on "It's Git, but <better in this way>", but none of them have really caught on beyond a small, admittedly passionate group.
I believe that's because once you go through the pain of learning Git, the idea of learning yet another distributed version control system or client seems so unappealing to most people that they'll never do it.
The truth is: if you're using GitHub or GitLab or some other hoster, you're already doing centralized version control; you're just doing it with a confusing distributed version control UX. I'm just trying to skip to the part where we just admit it and call it centralized and build something that makes that experience awesome.
When small trends change quickly - like, jQuery -> Ember -> Aurelia -> Angular -> React - the differences between them can be small.
When major trends change slowly, over decades - like relational -> map-reduce -> key-value -> document db -> graph db - the differences between them are usually much greater, and even if an older product adopts some piece of doing it the new way (think, SQL Server supports JSON storage well enough, but really you want to use a Document DB for that) it's a bolt-on or it doesn't quite fit with the design intent of the system.
Replacing Git is one of those large trend changes, and I don't believe that any "Git, but <better>" product will ever make that change happen. I think it's time for something really different, and a pendulum swing back to centralized, but with modern, fast cloud-native features and infrastructure, ready for high-scale monorepos and large file storage and effectively infinite repo sizes is the way to go.
I don't think there's a good, not-confusing way to build a distributed version control system. Others disagree, that's cool, and there are other wonderful version control projects like Pijul [1] and jj [2] and JamHub [3] and others who are trying to make a better distributed VCS. I know some of the people working on those projects, they're awesome, they care about doing it well, and I wish them all the luck in the world.
Something will catch on and replace Git, soon. Grace is my offering to that.
> There have been lots of projects over the last 10+ years that have been riffs on "It's Git, but <better in this way>", but none of them have really caught on beyond a small, admittedly passionate group.
I don't think so. The only ones I know of are Pijul and Jujitsu which you mentioned. They're both quite new.
> you're already doing centralized version control; you're just doing it with a confusing distributed version control UX
Sort of... But actually, as soon as you go offline it's distributed.
Anyway I think more alternatives is always better and lots of the issues you listed in the readme definitely need solving, so good luck!
Do you ever need to bisect regressions in a writing project? Do you need to maintain multiple releases and cherry pick patches across? Or does the latest version always supersede the previous? It seems like a far easier problem than what git is designed for.
I got used to real-time version tracking when I was working on a book. The publisher insisted that the working files are kept in the Box folder (like a DropBox, or any other cloud-shmoud synchronized storage). This was... convenient and practical. This way of working is much better than the Git way if you work alone and produce dozens or hundreds of meaningful changes a day.
But at some point you have to publish. You have to make sure your state is correct to some level of certainty, and share it with other people. So you still need some kind of 'commit' thingie.
I think, Grace gets this both ways right. Personally, I just keep GitHub repos in a DropBox folder, but if Grace catches on, I might consider hoping in.