Hacker News Reader

Comment by jimktrains2 | Hacker News Reader

> Note: we fell in love with DVCSes because they got branching right, but there’s nothing inherently distributed about a VCS with sane branching and merging.

No, I fell in love with it because it was distributed and I could work without an Internet connection, which aren't prevalent everywhere, and even in my house, in a large city, can be iffy. By work I mean things like blame, bisect, log, &c not just committing.

> Let me tell you something. Of all the time I have ever used DVCSes, over the last twenty years if we count Smalltalk changesets and twelve or so if you don’t, I have wanted to have the full history while offline a grand total of maybe about six times.

Well lucky him for only being able to code when he has a nice connection, not all of us do.

Also, I like the distributed aspect as well. I like not having to give people commit access to my repo for them to have a proper dev env and then they can send me a patch or a PR and we can incorporate their changes. How would they be able to make any commits or anything otherwise without access to my repository?

View on HN

I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do.

There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS.

Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git.

I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.

> I call that filter bubble. I like using git for local commits, but 15 out of 20 persons here don't even take their laptop with them and I bet that 17 out of 20 won't touch code on the road. Maybe at home, if they have to. A decent centralized VCS would totally do.

Maybe your team isn't a bunch of road-warriors but networks still drop packets, servers get overloaded and many people work remotely using imperfect VPNs & ISPs. It's really easy to forget how much time that used to waste but switching to Git meant that we no longer had daily chatter when any of those flared up & people just got on with life.

That said, I'd love to see some focus on tooling which improves the painful parts you mentioned. I'd love to share binary data in Git and it's possible but painful. Similarly, the main selling point for Git on internal projects is the massive performance and usability wins over most of the competitors but there's no reason why that must be the case other than inertia on the part of the other options.

Sure, networks drop packets and sometimes break down. But the number of issues with a solid office network is fairly low. Glass fiber, gigbit to the server. Folks don't work via VPN. I'm not pretending that the "road warrior" and remote worker use case isn't well served by git - but the "office worker tied to a desk" use case still exists. And from what I see is that it's more dominant than we'd expect.

> Folks don't work via VPN.

Plenty of people work via VPN. Not just people that have remote jobs, but people that just work from home one or two days per week.

VPNs are sort of primarily used to work via them.

Don't forget everyone working for a consulting company.

> But the number of issues with a solid office network is fairly low

The point was simply that “low” is not the same as “does not apply” and that matters when it's something which prevents someone from doing their job. Even when I worked at 100% on-site projects, I used git-svn so I could make local commits and ignore locking mishaps.

Don't get me wrong, however, I'm totally in agreement for having better tools for supporting the local, centralized workflow. The other reason I used git-svn was because merging was much more reliable and I could rebase changes to squash commits before sharing them with others. All three of those features should work well in any serious version control system regardless of whether it's centralized.

Your machine will stop working sometimes, far more often than your office network stops working(1) and then all your nice little, local commits which haven't been pushed so far are down the gutter. There's always a trade-off, you just have to know it and work accordingly.

(1) If this doesn't apply to your office network get a better network. Now.

This statement reflects a misunderstanding of the problem:

In either case, you will lose unpublished work in the event of a catastrophic local drive failure.

Only in the case of a centralized system, you will also be unable to work unless the entire network path and remote server is available. This will almost never be a question of data loss but it means that you will be unable to perform version control operations until it's resolved.

> Your machine will stop working sometimes, far more often than your office network stops working(1)

Bollocks. I've had two machine failures in eight years, versus at least 20 network failures. Sure, maybe the network admins at five different companies I've worked for all just happen to be a bunch of muppets, but I highly doubt it.

> Sure, maybe the network admins at five different companies I've worked for all just happen to be a bunch of muppets, but I highly doubt it.

That's your privilege. I don't. The only time I remember the network going down was after a complete air conditioning failure in the server room (a highly unlikely event in itself, but not IMPOSSIBLE) which forced a complete shutdown of IT services. And even then people could still work. Sure, not as well as usual but working was possible. The last time a machine failed was .. oh right. Yesterday.

Your machine, or anyone's machine? Remember to multiply a network failure by the number of people if you're doing that kind of comparison.

Also, get better machines. The last time a machine failed at this all-macbook shop was several months ago.

Entire remote offices work exclusively through VPNs to the main office. It's definitely a major usecase.

> I consider git a perfect match for loosely knit teams that are spread around the world and travel a lot. It's a great tool for OS development, but it's advantages quickly evaporate for teams that sit in a centralized location with a good connection to the server (cable, Gigbit) and only ever work from there.

Yes, I think what a lot of people forget is that git was designed specifically with the Linux kernel in mind. Linus wrote it to the workflow of his project without much regard for what other projects do. That's fine; there's nothing wrong with that at all. It just means that it's not suitable for every project, and that's a good thing: different types of projects should use tools that are actually designed for them.

It also explains why git has such a strong learning curve: it was written for kernel hackers. The only people who were expected to use it are the kind of people who are used to delving deep into the nitty gritty. It's why I'm kinda disappointed GitHub became the dominant public source code host, because Mercurial is IMO much better at actually being penetrable to new users. I think people who are mostly familiar with SVN would be far, far more at home with Mercurial than git.

Mercurial beats Git hands down across the board for me. I've worked on so many projects where the initial development was tossed into Git and then the devs spend three days trying to get their codebases synced and each using a different tool which may or may not implement the core commands of Git.

Mercurial? Works everywhere much more simply, even ties into .NET with VisualHG and gives a better version/branch management than TFS. And doesn't mismanage disk space like Git.

Mercurial + BitBucket is the cleanest, fastest way I have right now for adding devs to new projects. I avoid Git because so few people (ESPECIALLY those who have only used Git) understand source control well enough not to make a mess of it.

> each using a different tool which may or may not implement the core commands of Git

That's really one of the core problems of using git and why it's not for everyone. If you want a tool to do your job then git won't make you happy. Using the core tools and learning how it works _inside_ is the only way to make it work efficiently.

If you want/need a bike (something easy like svn), use a bike. If you want/need to use an air plane (git) you need to learn how to fly and that costs a lot of time. Putting something on the plane to make it look like a bike (a tool that may or may not enable all of git but probably not) won't suffice in either case.

Why must I be part of a team? Why can't I just be hacking randomly and syncing my history with my personal server as I feel like it.

> Why must I be part of a team? Why can't I just be hacking randomly and syncing my history with my personal server as I feel like it.

Sure, go, do. Just don't pretend that there are no teams and no other people that have different use cases.

Likewise, acknowledge that many other people have use cases where git works very well for them. That might have more to do with its popularity than a mad love for DVCS.

Go three post up, read the last paragraph. I'll quote it for your convenience:

Yes, and that argument was silly. There are many use cases besides dispersed teams and road warriors where git's weaknesses never actually come up and its strengths are useful. However, your arguments, like TFA's, rely on an unconvincing and entirely unproven premise that git doesn't actually suit most coders' use of it.

> However, your arguments, like TFA's, rely on an unconvincing and entirely unproven premise that git doesn't actually suit most coders' use of it.

No. The premise is "a system is conceivable that has gits upsides and less of its downsides" and look - facebook is even building it.

That's a premise so inane that it goes right into meaninglessness. Everything is "conceivable", especially "something that works as well as what I'm using in every way, but doesn't have problem X". It does nothing to conceive that, though.

As to what Facebook's building, meh. Anyone can try to build a better-in-every-way-for-every-application VCS, but look to TFA for a list of just some of the failed attempts to produce better version control mousetraps. It's more likely that they'll produce something that will be handy for niche uses than something that will be a clear win over git for everyone else.

> Sure, go, do. Just don't pretend that there are no teams and no other people that have different use cases.

Sure, there are. I've worked on them. I've had networking not work, servers fail, diffs take forever because of an overloaded server. Honestly, at this point, I can't conceive of working in a centralized VCS anymore, so unless you make a salient point about what can be done with one that can't be done with a DVCS it's all opinion vs opinion.

It's not only "for local commits", although being able to have local branches without polluting a public namespace is a huge win. It's also about _speed_ when you're doing VCS operations. Linus Torvalds actually made the case really well in his talk: https://www.youtube.com/watch?v=4XpnKHJAok8

> There are a lot of companies that actually would prefer if the code never left the premises and have a use-case for finer grained permissions (some folks can only touch the assets, others can only ever see the dev branch, can't see history,...), things that are by definition not possible in a DVCS.

That's a question that's completely orthogonal to whether or not you use a DVCS. How is a "traditional" VCS going to help you when you can check out the code locally and smuggle it out on a flash drive?

In my company, we use git and there are access restrictions as to who can access and commit to our branches.

> Storing large assets in git sort of suck and requires ulgy hacks. I'd love to version the toolchain and the VM images for the local development environment, but that's just not feasible with git.

..and that's not the use case for git. Linus has been very clear about _what_ git is optimized for, performance wise.

That doesn't mean that DVCSes in general are useless for storing large assets, but that the most popular implementation is. Also, I'm not really sure what traditional VCS you're referring to, that makes it easy to version VM images and remain storage efficient?

> I have wanted to have the full history while offline a grand total of maybe about six times.

I have probably run git init in a directory at least once a month to have full tracking capability without the expense of setting up a "server". It says something that the author assumes that a DVCS can only exists if it has a central server and that your local copy is nothing but the "offline" copy. I have also run projects where the github repo was just a copy and the version on my box was the official repo. I also run expensive (cpu/time) scripts that walk over the projects history, something the server admin would never let me do. And then we get into the realm of very expensive hooks that run on my desktop and not on the "server". And lastly even in an always connected world if your server is in Australia you can't change the speed of light, hitting it from Germany will always be a long "slow" trip.

Having the full repository at your disposal without being tied to some other authoritative repository provides a lot of flexibility and enables capabilities that are just not possible otherwise. Some features could easily be included in non-dvcs systems (such as local hooks), but I do not know if we would have seen their success without dvcs systems providing the means for exploration.

Agree with you 100%, any project, no matter how small, gets "git init"ed with me simply to start tracking it in case I later regret that change I just made.

And I love that if I need it on another machine it's just "git clone ssh://..." instead of having to setup a server.

Well, I mean, the author goes on to make a bunch of salient points like the difficulty of diffs of nested directories (solved in [1] but not widely implemented) and saving all of the binary blobs in every checkout (solved by [2] which has not "won out").

I think the big thing with DVCSes is that you can pretend you have a client-server model with a handful of directories on your local machine. At one point at my present job I replayed a bunch of SVN history through Hg so that I could by-hand divide the work that had been done into a few named branches; this helped me to figure out where things had "gone wrong" in the project. It was really effective to just have a day of SVN update, hg diff, copy files to ../branch_name, commit to hg, rinse, repeat. What I really needed was indeed the "killer feature" that he's saying -- sane branching and merging -- but the fact that it was all easily contained in my filesystem was a nice plus.

[1] http://www.cs.utexas.edu/~ecprice/papers/confluent_swat.pdf

[2] http://darcs.net/Internals/CacheSystem#lazy-repositories-and...

I fell in love with git because it's FAST. And it's fast because it's distributed.

Have you ever used Perforce?

You mean that proprietary code? No, I avoid non F/OSS at all costs.

Wherein it is pointed out that Hacker News is proprietary software.

Really? https://github.com/wting/hackernews

Where is the license file? Just because the code can be viewed does not make it legal to use or that it is "free" or "open source".

https://github.com/wting/hackernews/blob/master/copyright

Hacker News is a website (so even with their code being open-sourced, I cannot verify what exactly they're running anyway), not software I'm running (JS aside).

The firmware on the routers between me and the server are proprietary, and there is nothing I can do about that.

I can choose not to run proprietary software without having to not use the web.

You sure about that? Your system will be full of proprietary firmwares, drivers, etc.

I avoid it as much as I possibly can. I don't know what more to tell you. I never said I'm proprietary code-free, but just that I avoid it at all costs.

Hell, I've recently been forced to install proprietary code to work with government generated data. Such a mess.

I have, and at least at my work, it's terrible. Sometimes it gets to the point where my submit requests time out several tries in a row. Yes, I'm sure it's because the people maintaining the server aren't doing it properly, but that's sort of the point. With git, you don't have to worry about it.

> With git, you don't have to worry about it.

Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.

But at least you can run git log and not have to wait minutes.

True. You are spared some of the pain, but not all of it.

Ironically, Perforce doesn't even have proper search in commit history when it's working as designed. No need for the server to break...

> Wait until you see a badly managed git server that serves a central repository. You'll quickly change your mind if pushes start failing randomly.

But I can't code a better sysadmin into either git or Perforce. A badly managed Perforce server will have the same issues. (Unless, of course, you have an argument that Perforce under bad management somehow performs better than git under similar conditions.)

With git, however, I can still commit, and I can still push and pull changes from other people using side channels such as email. I can, for the most part, keep working. Is it more difficult? Of course. But in the particular scenario, git outperforms Perforce, in my opinion. (But this is not the primary reason I use git; at work, we use GitHub and git in very much a centralized manner. GitHub has its outages, and they're annoying. But not work-ending.)

The GP's words were: "With git, you don't have to worry about it."

I never said that perforce would perform in any way better, but I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around. Try pushing your changes via email to your CI server. Fully decentralized would be beautiful, but I seriously don't see many teams that use git (or any other system) in that manner. Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.

I was responding to you. :-)

> I'd argue that if your VCS server is mismanaged you'd better change the person managing because a badly managed VCS means trouble all around.

I agree. The first time I read your argument, I interpreted it as a reason to not use git itself, but I think we're on the same page.

> Some parts of the infrastructure fundamentally end up being centralized, as stupid and wasteful as it is.

What else can be done? I don't really want to push changes to my co-workers individually, I want a place to push changes that any co-worker can then pull from — do I not? Toward this goal, certainly I could create n servers, and make pushing redundant over those n servers, have then do consensus to agree on HEAD, etc., but that seems to me to be what I'm paying GitHub to do.

There are good managed git services for companies that don't want to run their own. If my sysadmins are truly incompetent I can use a free private bitbucket repository.

If Git pushes start failing randomly, it isn't even a failure: no file has been harmed, and a new central "server" can be freely improvised.

Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce.

There are cases when P4 is the only choice (large binaries come to mind, and really really big code bases) but it's the kind of thing you shift to because you have to, not because you want to.

I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't.

When looking at an actual example of the latter [1], you will see that they are heavily optimizing against contention on the central database by limiting the size of database operations. If you want to do something that would require a longer database query: Enjoy your client side error message about implementation details you never wanted to know about.

[1] http://research.google.com/pubs/pub39983.html

> I believe you are conflating two aspects: Large binaries, which are, in very specific circumstances, a (or maybe the only) valid reason to use Perforce, and large codebases, which usually aren't.

Unfortunately I did not mean to. I would agree with you that binaries are the 95% use case for P4. I think most developers typically wouldn't want to check many or any binaries in (maybe the odd icon or other small, slowly-changing asset, in which case git is adequate), but game developers and people with other binary stuff (e.g. circuit designs) will have large, changing binaries.

However really big (GB-scale) repos can be painful in git. This is why google gritted their teeth and used P4 until they outgrew it too. That's what I meant by "really really big" -- something of the scale that most of us will (hopefully) never see.

> Maybe it's just me, but "fast" isn't something that comes to my mind when I think of Perforce.

Agreed. I use git-p4 for interacting with p4 servers here at work. I love that I can create my commits and make them as granular as I want without having to interact with the server until I'm ready to submit my commits.

Using git-p4 means I don't have to 'p4 edit' my files before I edit them (which really sucks when the p4 server isn't available for any reason), I can simply put off any version control workflows until I'm done with my changes (and slice and dice the changes the way I want with interactive rebase).

Thinking of all the little interactions I do with git which a) aren't possible with p4 or if they were b) would involve talking to the server every step of the way makes me cringe. But then out of necessity, p4 developers probably aren't creating such fine-grained commits like I like to do (and indeed isn't even possible without a lot of fore-planning with p4), so they wouldn't notice the speed impact.

I quit my job because we were stuck using Perforce - how's that? :P

Try the git-p4 contrib. It has its issues, but it's not bad if you're forced to use p4.

I'll second this. git-p4 kept me sane through several years of working in a very large perforce shop.

Perforce is not fast, it cheats: You tell the server in advance what you are doing, so that the submit is fast. This comes at a tremendous price: Your editor/IDE has to have a perforce plugin to do what should be the VCS' job (tell perforce what is happening in your workspace), and the connection to the server has to be reliable and low latency, lest you want to spend seconds every time you make an edit in a file that has not been checked out already.

In practice, this model is a constant source of frustration, and everything Perforce has done in the last few years seems to be workarounds for this broken architecture.

Perforce sucks. From a UX perspective, it really is rotten. Furthermore, contrary to popular belief, it scales poorly.

Perforce scales provided you can continue to throw money and hardware at the machine your repo is on. After a while, for large software companies, that is no longer feasible. You have to split off into multiple perforce repos, at which point you abandon the benefits of a monolithic repo.

I have seen a very large software company abandon perforce for git for this reason. You can't push a single git repo as far as you can push a single perforce repo, but you can push a fleet of git repos way farther than you can push a single perforce repo, and a fleet of perforce repos is something you really don't want to deal with.

For those wondering, Perforce just announced their own DVCS implementation[0][1].

[0] http://www.perforce.com/blog/150303/introducing-helix

[1] http://www.perforce.com/helix

I have used it for some full moons. I didn't like it. This was before I learned about DVCS, so my only real reference was SVN, but for what I did (medium-size business apps, a few years of history) I can't say it felt faster than SVN.

OTOH Perforce had some serious downsides like

  * immature eclipse plugin (would crash eclipse more 
    than once a week, forcing a full reset every.single.time)
  * no Netbeans plugin (back then)
  * the whole idea of having to decide in advance, -while in
    the office or otherwise connected, which files you 
    needed to modify and therefore "check out" -
  * which brings me to the next problem: by default only one 
    person can work at a file at the same time.

YMMW, I see some people liking Perforce, OTOH I see people using Macs for coding as well. (That last part is tongue-in-cheek, yes, I really wish I liked Macs and I recommend everyone to consider them.)

* until you work on a project which has a 9Gb repo and history...

You can do a shallow clone in any reasonable versioning system: http://stackoverflow.com/questions/6941889/is-git-clone-dept...

But then git blame or bisect don't really work anymore.

It may work well enough.

I'm not too sure what could be realistically done to implement offline bisect without getting the all the history you care about.

One approach would be to query the server for these operations. And unlike what happens in Git, where blame is an O(N) operation, a centralized server is free to spend some extra storage to add some caches or indexes to make these searches faster.

Querying the server rarely works when you're offline.

but then you lose the ability to git bisect, blame etc, which is the root comment's advantage of doing git.

I've worked on a project where the git repository was man gigabytes - because at some point someone decided to put some binary files in the repository, which periodically got updated - now years on the repository's about 10GB, and you can't really delete the stuff clogging it up without rewriting history from years prior and making the 200 devs life hell.

Importantly, you do need all that history, because there are commits from the same time that are relevant.

And if you never do, even after fifteen years working dozens of different project? Including a few projects that have run for most of those fifteen years?

I agree that git is weak for binaries, but the only binaries I need to keep in it are a few images and installer - nothing that has many versions, nothing that causes me problems. Similarly, a lot of open source software is mostly made up of code, not blobs.

As for distributed work, even when I'm the only developer on a project, it helps not to have to worry about a central server, especially if I'm on-site. It's also hugely faster than SVN ever was.

9 Gbit really aint that much.

Ours is 370GB. git-svn typically falls over and dies on that, if you're brave enough to try.

370GB is peanuts. Try keeping a centralized version control server up and operating when you have dozens of terabytes and thousands of developers.

Better to abandon the ultimately doomed monolithic repo scheme and tool your build and deployment systems to expect a multi-repo ecosystem. Then allow your teams to create their own repos on the fly, one for each individual project if they please. Once you reach that point, there is little reason to not use a more sensible VCS like hg or git.

>Well lucky him for only being able to code when he has a nice connection, not all of us do.

So basically, you're de facto the field tech example he gave, out in the virtual wilderness of iffy internet.

No, I'm not a field tech. I'm a hacker. I work where I am and when I'm in the mood. In a pavilon at the park and idea strikes? Hack! At home and my internet goes out? No Problem!

At the park when an idea strikes? Write it down on a piece of paper. No need to have your face buried in your computer every second you're at a park.

Edit: All you have to do it jot down the idea if your worried you'll forget about it. You don't have to hand write out all the code that would be silly. I find having a small notebook with me is pretty handy.

It's no better to have your face buried in sheets of paper. And who carries paper and pens around anyway?

For the record, I carry a journal and pen in my pocket all the time. Writing down phone numbers and notes, taking a log of my life, keeping cards from businesses. Looking back through them is much more enjoyable than looking back through a Wordpress.

http://shop.moleskine.com/FileLibrary/4be794eb3e094e59ac8a8f...

I was being a tad facetious. I used to as well, but these days I just use a smart phone or tablet with a suitable note taking app, since I always have one with me anyway. My main point is I don't see the difference between taking notes digitally or on paper.

Are you taking your laptop with you to the park 'just in case'.

I sometimes am. Definitely when the park happens to be in another city I went to visit for some reason - I feel bad without having a proper computational device with me for longer periods of time. What's wrong with that?

I often have it with me because I'm normally out to meet with people and collaborate, but stay out before and after:)

Really? This is one hell of a filter bubble.

Not entire world is a goddamn Sillicon Valley. Internet is not electricity, and won't be for a while - free and reliable WiFi ain't everywhere; sometimes you work where you're not allowed to connect to a network, sometimes your ISP decides to fuck up the link for an hour for no reason whatsoever, the other day you work at a venue with office-grade Internet (i.e. slow as hell). And then you might want to hack during commute. Data plans are expensive, not every place on Earth has LTE connection (or any form of reasonable data connection for that matter) - and I don't mean wilderness, I mean the highway between two big cities. And try to tether your laptop to your phone, and then suddenly something decides it's time to download 2GB of software updates and boom, there goes your plan.

Above all that, what happened with the concept of owning the data? I want my stuff available off-line, because it's mine, period. I want to run arbitrary code I write on it, and hell, I sometimes want to open the data in text editor and edit by hand. Moreover, doing constant round-trips around the world to do things that you should be able to do locally is kind of stupid.

EDIT:

And don't tell me about YAGNI and stuff. Version control is infrastructure, and the iron rule of infrastructure is - you use what you have; the more you have, the more you use. If you give me a feature, I'll adapt my workflow to use it, even though I was fine without it before. Cutting down on infrastructure reduces the amount of things people will create with it.

>Not entire world is a goddamn Sillicon Valley. Internet is not electricity, and won't be for a while - free and reliable WiFi ain't everywhere; sometimes you work where you're not allowed to connect to a network, sometimes your ISP decides to fuck up the link for an hour for no reason whatsoever, the other day you work at a venue with office-grade Internet (i.e. slow as hell). And then you might want to hack during commute. Data plans are expensive, not every place on Earth has LTE connection (or any form of reasonable data connection for that matter)...

So, in other words, like someone working away from home base...like someone...in the field. I suppose I wasn't clear. I had hoped my use of "virtual wilderness" implied a different domain for "field" that is not necessarily a physical location.

>Internet is not electricity

And there was a time where electricity wasn't ubiquitous either (and it still isn't depending where you are). Such places, then and now, could be reasonably described as being relatively in the field.

>and I don't mean wilderness, I mean the highway between two big cities.

That could definitely fall under working in the field, especially compared to an office.

>Above all that, what happened with the concept of owning the data?

Choose whatever VCS you like for whatever reasons you want; it doesn't matter to me. I'm merely pointing out that I think the author covered that base. You may not be underwater in a submarine, but if you're on the road on your laptop trying to scrounge for LTE or zipping from firewalled office to firewalled office, you may as well be virtually underwater with respect to the Internet.

Anyone can work without internet. You just don't commit. If you really need to commit without internet, you're probably an edge case. It's a bonus, but not something I'd choose a VCS system for. My central repo is where the build server is looking, so if I'm not connected, I'm not deploying no matter which VCS I have. The repo is most definitely centralized.

I suspect some of the down votes are because what you mean by commit and what a git user means by commit is different. I suspect that most people using git are "committing" in a way that would better be handled with a versioned file system.

AKA, translated for the git people, "you can work without the internet, you just don't issue pull requests (or pull for that matter)".

Where I work now we still use CVS, and frankly it works fine (even with large binaries checked in). I ran git-cvs for a while, and had a dozen different branches for all the separate features I was working on.

Then I found I was spending a metric crapload of time messing with the version control rather than writing code. CVS may be basic, but in a way that is a plus. It strongly encourages you not to have 20 different features being worked on at the same time, then merging this piece here to that piece there. No, its simple: Work on one thing in your working directory, commit it to the head, pull everyone's changes, go work on the next thing. Repeat.

Eventually I kicked my git-cvs to the curb for plain old CVS. Gives me more focus.

Now I can waste the time I spent on stack overflow (learning how to fix my git screwups) posting here...

Yeah, I was using "commit" in the SVN sense. Which is another good complaint against git that it rewrote the established lexicon to mean different things. Sure a git commit may be technically equivalent to an SVN commit, but when I "commit" I mean that I'm blessing a change as ready to share via a shared repo.

Reply on news.ycombinator.com