Not being able to work offline at all seems like somewhat of an issue.
99% of the time it's fine, but if you have even one thing you want to do locally, now you have to use two separate tools.
I'm not sure how many people have an absolute hard requirement for local operation, but it is a nice extra layer of peace of mind.
Git might not be perfect, but it's one of the only tools witch such a large market share. All your projects can use the same VCS, which is really nice.
On the other hand, some programmers seem to really like having different highly specialized tools for every job, rather than adapting jobs to fit the tools, so I'm sure there's demand for a new VCS there.
> Working from a hotel coffee bar and the WiFi goes out? Bummer if that blocks your work.
Grace doesn't change anything about that for you. You still write code locally, and `grace watch` will sync you up when you reconnect.
You can't `git push` without an internet connection, either, and you can't work on your Azure / GCP / AWS resources. Or your Google Docs. Or your email. Or your Teams chat. Source control isn't a special case that must work offline, it's just that we're used to Git, and we pay the bad-UX tax of using a distributed VCS as a centralized VCS, because very few of us push to production from our dev boxes, only from a (Git)hub.
Assuming a working internet connection in the late 2020's (i.e. roughly when Git will be replaced by some competitor) is not a blocker for almost every developer in the world. And Git will still be there if offline usage is a hard requirement.
Hard disagree. It’s inherently true that I can’t work on remote servers and all those things but VCS are not inherently remote. I have entire local hobby projects I’ve never git pushed anywhere because my local copy is authoritative. We as an industry largely moved off centralized VCS because of those advantages of having 100% functionality on an airplane.
> I have entire local hobby projects I’ve never git pushed anywhere because my local copy is authoritative.
Isn't this backward? Your local copy is authoritative because you've never pushed anywhere (-:
I know it's probably overkill and you should just use git (or just use folder backups or something if it really is just local) but you could in theory run the grace server locally too, I imagine.
> Not being able to work offline at all seems like somewhat of an issue.
I agree. If it's intended to be a web-based system, why not have it running as a webserver on your local machine?
Also, the intention is to have a GUI, or rather 4 or 5 seeparate GUIs:
> Grace will have a native GUI app for Windows, Mac, Android, and iOS. (And probably Linux.)
But if you're having a web UI, why have a GUI as well? It is just extra work, and it is quite likely that the UI for these tools won't be the same, potentially making them harder to learn.
The intention is that they'll be identical, because they'll be written using Avalonia.
And I hate Electron. I hate it so much. I hate the web pages that I'm being told are "apps". I hate the lack of keyboard shortcut support. I hate the bad performance. I hate how it's not stick-to-your-finger fast. I hate owning unbelievably powerful computers and mobile devices and not taking advantage of their power and capabilities, and just reducing them to surfaces for fake "apps".
I'm not a fan of it either. When I say have a web UI, I don't mean electron, I mean the program runs as a web server on some port your local machine and you point you web browser at it.
I don't think electron should exist.
> I hate the lack of keyboard shortcut support
And I hate the existence of keyboard shortcuts, or at least hard-to-discover ones. On a daily basis I accidentally press keys (I've no idea which ones) that make my windows misbehave.
I also don't think I should have to learn keyboard shortcuts -- interfaces should be discoverable and not require you to memorise stuff.
> I hate the bad performance.
Then use a text UI not a GUI. Back in the day, Borland made extensive use of these for Turbo Pascal and they worked well and looked good. As a bonus (like a web app) they can run easily on an external machine.
> I hate how it's not stick-to-your-finger fast.
I've used git for years and before it other source control systems. I don't remember a single instance where the slowness of the source control system was ever a factor.
I don't develop offline often these days, but I do recall a recent time where my power went out for a few hours. Since I was using git on my laptop, I just shrugged and kept working. Using git allowed me to continue working in a flow state that would have normally been interrupted by a dropped connection. Of course, if your project doesn't run locally, that point is moot. For others, in areas with more power/connection interruptions, the time savef would add up.
I don't develop offline, but I've developed the habit of making lots of tiny commits, then rebasing them into a single commit before pushing. To me, a commit is for something I might want to undo and a push is for something that I either want to share or am afraid of losing. I'm not suggesting this is the best way to use version control or even a good way -- just that it's a habit I've developed and don't really want to unlearn.
99% of the time it's fine, but if you have even one thing you want to do locally, now you have to use two separate tools.
I'm not sure how many people have an absolute hard requirement for local operation, but it is a nice extra layer of peace of mind.
Git might not be perfect, but it's one of the only tools witch such a large market share. All your projects can use the same VCS, which is really nice.
On the other hand, some programmers seem to really like having different highly specialized tools for every job, rather than adapting jobs to fit the tools, so I'm sure there's demand for a new VCS there.