
Today’s Version Control Tools Are Still Primitive - kartickv
https://medium.com/@karti/todays-version-control-tools-are-still-primitive-8d37e8e8f9a5
======
languagehacker
If you've used Git for only a year, and you've got a mere "hundreds of
commits" under your belt with distributed version control systems, then the
pain you're feeling may not necessarily be coming from the tool.

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.

~~~
kartickv
Author here.

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.

------
lozenge
Is the author using Google Drive sharing as a substitute for a Git server like
Github?

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

~~~
kartickv
Author here.

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.

~~~
Terretta
[https://codenvy.com](https://codenvy.com)

------
Myrmornis
Several of the authors complaints stem from him not using temporary branches
liberally. I think he’s suffering from the common beginners’ problem of
thinking that committing has to be final. The word “commit” doesn’t help;
“snapshot” might be a better metaphor. But even if you understand that a
commit is cheap, and disposable, it takes quite a bit of experience to get
comfortable using the graph comprising different branches, and to be confident
with remote and local branches. This learning curve could be said to be a
problem, but personally I don’t really want software engineers as colleagues
if they can’t learn git.

~~~
kartickv
Author here. You're right -- I haven't created even one branch so far, let
alone liberally. But snapshotting should be automatic, like in Google Docs.

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.

~~~
Myrmornis
OK, I hope the tone of my original post wasn't unpleasant (on re-reading, not
sure I'm a huge fan of it). It might be interesting to have a version control
system which does continuous recording. If git is the last word in VCS then I
guess humans didn't live for much longer! But personally I am completely happy
with the current style in which the user explicitly creates snapshots and
these form a distributed graph, and the user is given tools to work with the
graph.

~~~
kartickv
Thanks for clarifying tone.

------
luckydude
Sadly, Git won. BitKeeper solves a bunch of this stuff, not all, but a bunch
but nobody cares. The reality is GitHub won. To 99.99% of the world version
control is GitHub. Step outside of what GitHub can do and you get blank
stares.

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

~~~
kartickv
Interesting, and sad that Git won.

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.

------
jabot
This article has a few points.

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 :-)

~~~
bitwize
I, too, want a pony.

~~~
kartickv
Preemptively reducing your expectations is a great way to ensure that we won't
take big leaps forward. You can choose to be sarcastic, while I'll keep my
positive, hopeful attitude.

------
hasenj
It seems like most of his demands can be solved with Dropbox or a similar
cloud sync software.

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.

~~~
kartickv
Linus needn't have on his disc every random person's WIP. The software can be
smart enough to only sync code he's tried to read, edit or compile. Or Linux
can choose. An analogy is Google Drive letting you choose which folders to
sync down to your device. The point is that there are many better solutions to
the problem than people never want to see each other's work, which is the
status quo, and requiring them to jump through hoops if they want to.

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

------
sytse
This article really resonated with me. Especially the integration is something
we can uniquely do. At GitLab we'll build the GitLab IDE in 2018. It will be a
single user thing at first but the article has a couple of great ideas for to
do it with multiple users.

~~~
elygre
Ah, please don’t.

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.

~~~
kartickv
That's the problem with enhancing existing tools — you have to choose between
satisfying existing customers in the short term. The best vehicle for my ideas
may be a new tool built from scratch. Sure, reuse code fragments or libraries,
but don't feel constrained by backward compatibility.

------
AkshatM
Nearly all of these features are appropriate to a cloud-based IDE with sync
capabilities, not a distributed version control system. The author even
acknowledges he's thinking of such an IDE by referencing Cider.

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.

------
amelius
This article could just as well be titled "Today's OSes are still primitive".

------
gbtw
This seems all nice to have but what I really miss is the software engineering
side integration into the whole development side. You should have the software
engineering people who make J-STD-016 or similar traced requirement, design,
test and deployment documentation all the way into the code. Heck sometimes
generating code & tests from documentation is really valuable in a large
system.

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

------
qznc
I like that this is not just a rant about git. Instead there are quite
specific demands which are really not available anywhere.

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.

------
xq3000
You are talking about much more than just version control here. And, yes, a
web based IDE with web based workspaces is probably the way to go.

I think Eclipse Che is doing _exactly_ that today and is production ready.

------
mankash666
Concur with #7 & #8. IDE support & support for large repos seem basic. Other
features are not strictly within the scope of VCS, but things that we've come
to expect in 2017. I'm for keeping them separate

------
Snappy
A web IDE is a great start, and as Sid already pointed out, at GitLab we'll
ship an IDE deeply integrated with version control (and CI, CD, monitoring,
etc.) in 2018.

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.

