Today’s Version Control Tools Are Still Primitive
medium.com
medium.com
Many of your unmet needs basically boil down to a desire for automatic replication of the state of a codebase to a remote endpoint. Right now, it's an explicit choice made by the developer. There are a lot of good reasons for this. If you don't feel like any of them apply to you, it should take you maybe half a day to write a script that creates a throwaway commit and is pushed to an arbitrary remote. Or you can just put your project in Dropbox and call it a day.
Also, if you're looking to work on a Git project using a Chromebook, maybe just use the inline edit mode in GitHub.
In all, I don't think the features you're looking for necessarily belong in a distributed version control system or its related protocols. As I've outlined above, you can get what you want by extending such a system, or using existing extensions on top of those systems.
far as backup is concerned it just a tarball to nfs. alternatively one might look at something like gitfs. My problem with such 'overly integrated solutions' is that they work until they dont. if git were to do it the okay but what if you are dealing with multiple git repos? what if some of them are gitfusion repos from perforce backend? IMHO simple & deterministic (as in deterministic to human mind) is better.
You're right that I'm a Git beginner.
I don't want to hack up my own distributed version control system that fails in interesting ways :) And yes, I do put my Git workspaces in Google Drive, but that doesn't address many of the limitations in the post.
Github's inline edit mode is exactly the kind of affordances we need. When I needed to make a simple change to my open-source project (adding comments to document assumptions), I didn't want to mess with downloading, resolving conflicts, merging and pushing.
Regarding your point that this doesn't belong in a version control system (a point that other people made on this HN post) but in extensions, I want an integrated environment. I don't want to investigate extensions and hooks and scripts to make things work together. I want it to be seamless. Just like IDEs are different from text editors (and upset some old-school programmers that "XYZ shouldn't be in a text editor"), I'm advocating a new style of version control system that does more.
> That frees him to modify the code as he sees fit without worrying about whether he’s accidentally throwing away my work, making me unhappy.
Git already keeps history!
> I should be able to instantly create another workspace. Currently, syncing everything down from the server takes 10 or 20 seconds
It'll only take a moment with `git clone --shallow` and you can then run `git fetch` in the background.
> The last time I switched branches in Git for this, I accidentally had an unsaved change in my text editor. When I later pressed Cmd-S, it got saved to the wrong branch.
Use a text editor that knows Git. This is unsolvable with a text editor that isn't integrated with your version control.
> If you want to keep two versions of code, the filesystem already offers a solution. It’s called folders. That makes it easier to switch between them, as easy as minimising a window. It’s hack to have only one folder and copying files back and forth to simulate having multiple folders.
git supports having multiple folders with different versions of your code checked out: https://git-scm.com/docs/git-worktree
The entire CPython repository is 300MB (less over the wire thanks to compression) and once it's downloaded, Git can answer just about any query you can think of in under 100ms, or as the author says, "instant". I'll take that over some complicated smart-sync cloud solution any day.
I have all my Git workspaces in Google Drive, but that's a hack, because I'm using two cloud systems (BitBucket and Drive) together. It would be like editing some Word documents by keeping the intermediate versions in Dropbox but the result in Google Drive.
> Git already keeps history!
Not for uncommitted changes. Like edits in Google Docs. Being able to go back lets me freely modify the code to try out something else knowing I can easily go back. Without making intermediate commits, branches, a second workspace, or other overhead.
> This is unsolvable with a text editor that isn't integrated with your version control.
Actually it's solvable, by having different workspaces instead of branches when I want to try out two different approaches to see which one works better.
Thanks for suggesting worktrees, but given Git's complexity and poor UX, I try not to get too fancy :) But you're right that does work instantly. I'd like instant performance + easy UX.
It's not that someone "can't learn git". Learning is a process, and takes time. But I have no sympathy for tools with an unnecessarily steep learning curve and poor UX like Git. I should have to pay that price only when I want to do something very sophisticated that only Git can do. Not for basic tasks. Simple things should be simple and hard things possible. Snapshotting should be automatic.
If you want to play with BK, it's at bitkeeper.org, all open source, apache v2 license (because that seemed to be the license that most people liked, contact me if that doesn't work for you).
I used Mercurial earlier, given that it seemed to have a better user experience, but Xcode's integration with Git made me switch.
Thanks for your offer.
First of all, the author wants backup, switching machines, and collaboration all integrated into VC. This is a worthwile goal, and i can see that shoehorning git et al into those rules can feel... clunky. I think there is room for improvement there.
The author comes off a little greedy, when he wants to (a) be able to instantaneously create a new workspace while (b) being able to manage huge code bases. Oh, and everything should work even on his chromebook - as long as he has one computer that can do the work, all his other computers should offload the work to the one capable of doing it. Transparently of course.
This sounds great and all... but i would not want to implement it :-)
Git will likely never implement his ideas because git is designed for decentralized workflows where you can have hundreds of people working on different things in the same large repo. Why should Linus have on his disc a copy of every single WIP branch of the many people currently hacking on the Kernel? This will never happen. It's completely outside the scope of git.
Git will never implement my ideas, and I wasn't asking for it to. I was calling for a new kind of integrated version control system. It's like an IDE vs a text editor, and many old-school programmers saying, "No, that shouldn't be part of an editor".
The article seems to assume tight coupling between tools as a prerequisite for seamless integration between them.
I am the maintainer of git-appraise, and its founding precept is that tools can be loosely coupled and still seamlessly integrate together. All they have to do is store their data in the git repository in a common format.
The result works well. For example, a commit can be built by both Travis and Jenkins, and other tools can show both results without caring which tools produced them.
The rest of the suggestions seemed reasonable, though.
I love GitLab, made it a corporate standard accessible to every single employee. But the current problem space is already huge, and you are struggling to solve all of it properly.
Branching off into an entirely new dimension, like an IDE will be, will make it even harder for you to satisfy existing customers.
A DVCS does one thing and one thing well: it enables copying one history of a codebase to different clients. Broadcasting updates to a client's particular history to all other clients in real time is not its job - yet all the listed 'desirable' features (with the exception of those citing performance) seem to do just that.
Now we get around this by making Jira tickets and hanging jira tickets in change requests and change requests have documentation changes but really i would like to pull up any piece of code and read all the requirements and the design decisions that are made on it.
Is something we miss (30 man year sized project, with 3 full time engineers, both software engineering and coding) and is more of an imitate problem once the software becomes to complex to hold into an engineers head (i try ;)).
I think this goes beyond version control though. To move computation seamlessly integration with lots of parts is necessary. I think something tightly integrated like Smalltalk would be the best path to build a prototype.
I think Eclipse Che is doing exactly that today and is production ready.
But that only covers part of the problem. A lot of the post revolves around newer concepts of realtime as exemplified by Google Docs. Specifically I mean:
* Realtime
* Collaborative
* Versionless
An IDE is obviously realtime, but our focus is on single-user realtime, at least initially. CodeEnvy, Koding, and others have created shared editing environments, so maybe that's a pattern that works. But that still doesn't sound like what the author is really looking for. These are editing environments built on top of git so require the same branch and commit model. e.g. if you forget to commit your changes, anyone looking at the code outside of your (shared, collaborative, online) environment won't see it.
I've been wondering for a while what the next iteration of VCS (or DVCS) is going to be, and I have a hunch it will involve realtime.
What would it look like if the underlying VCS was realtime itself? If it worked like Google Docs?
I imagine it kind of like Google Docs's "suggesting" mode, where edits are shown on the mainline, but as suggestions which can be accepted or rejected. That's kind of like merging a merge request or pull request. But it doesn't seem to scale well. Imagine a doc with hundreds of simultaneous suggestions on the same code, especially stale suggestions that you aren't going to merge, but aren't ready to delete either. Would you switch between groups of suggestions/suggesters (like you would switch branches)? Would you just not work with long branches? I mean, that's an anti-pattern anyway. And don't even think about branches of branches or applying a patch to the last N stable branches. But if you're doing continuous deployment to a web product, those patterns don't apply anyway.
Would being forced to see all the suggestions trigger latent OCD and cause people to clean them up constantly? Or would it turn out not that bad because you're only seeing simultaneous changes on a single page at a time?
That brings up another challenge, changes that spread across many different files, but need to be considered together to make sense. Google Docs rarely have that problem. Maybe that means that it's inherently incompatible. Maybe it just needs a new solution we haven't seen yet. One idea comes to mind: the way recent editors show a mini-map of a file, and when you search, all search hits are highlighted on the mini-map. Extend that in some way so that when I'm looking at one suggestion, related suggestions are highlighted for me. I don't know, might be a dumb idea, but the point is that some thinking out of the box might solve this.
Google Docs (and realtime collaborative editing in general) were such a game changer that people flocked to it even though it was seriously under-featured compared to Word. Sure, tons of enterprises are still on Word, and there's a bit of a gap between companies that have embraced Docs or not. But for those that did, it's changed how we work. Keeping everyone in sync is far more important than having 10,000 options for making words follow a curve in 3D.
I wonder if some realtime version control, applied to code, will open up new ways of working we can't even conceive of today, and we'll slowly forget that we once loved the branch and commit model.