I wouldn't use git if it didn't have cheap inline local branching. It is the Killer Feature.

That may be true (honestly, I don't know), but I haven't yet needed to maintain different branches of projects I'm working on and so it's a non-issue at this point. If at some point it becomes an issue, and I find Mercurial lacking, then of course I'll take a closer look at git, who probably does it more appropriately.

A stopped clock is right twice a day.

Remote work especially is bonkers. Push/pull? Easy. Add/Delete remote branch? Off to google for me...

Not knee-jerk arguing, genuinely curious. When I compared them on Windows and OpenBSD, I never had a speed difference of more than about 5% (not counting git db repacking), even with a project that had 40,000+ commits, 10+ very active branches, and about 2 GB of code + data.

It's nowhere near an actual analysis, just my experience in my limited use (and probably influenced quite a bit by things that I've heard).

(I was using an actual timer when I compared them.)

I don't think anybody would suggest that size of repository matters for the number of bytes involved. There are obvious side effects of a large repository.

I work on amd64/i386/sparc OpenBSD at home and Windows at work, and I think version control systems are one of the tools that should be especially platform-independent: How will you port your project to another platform if you can't even track patches for it there?

I'm not saying that it doesn't work, just noting that so you can make an informed decision based on your priorities. I hear a lot of buzz about Git, but hardly anybody mentions this, and changing VC systems with thousands of commits can be extremely painful.

Where Git is written in a mix of C and sh scripts* , Mercurial is written in Python (except for a few parts written in C for speed, such as its diff algorithm), and its design seems far less coupled with any particular platform (and much cleaner overall, IMHO). I spent an afternoon importing a very large project (40,000+ commits, 10+ branches) currently using perforce into monotone, git, and mercurial repositories, and compared them. (This was on Windows.) The git interface seemed in many ways too rough around the edges to me, and while it was very nearly as fast as mercurial (and a bit faster than mtn, even with cached inodes), the database also needed to be re-compacted. Mercurial was much, much more straightforward to use than either mtn or git.

* $ grep "#!/bin/sh" /usr/local/bin/git* | wc -l ===> 23

Could you give me a reference to "git is not quite as fast on OS X" because I certainly haven't noticed it. On windows I could feel how slow it was, but not on OS X.

i've been using cvs for about 10 years now and have no reason to switch to anything else. it does what i need without any extra fluff, all my projects are in cvs, and the majority of the projects i contribute to use cvs.

git add .

git commit -a

yes, it's two commands but in return git will automatically find new files, internally delete files you have deleted, and even automatically find renamed files (under most conditions).

I don't have a great argument about why we chose git over mercurial, it seemed like the right choice. But I can tell you that git is a lot better than svn for our purposes.

I find it somewhat funny about the complaints of git being difficult to use. Personally, our team found svn difficult to use due to having to micromanage moves adds and deletes.

edit: also, not having a bunch of .svn directories peppered all over your directory structure is nice, just one .git directory at the top. You can move directories in and out from other locations without worrying about anything.

1. They're scientists who need to do some programming, rather than programmers who need to do some science, so the command line is acceptable but confusion and complexity are not.

2. Remote hosting is not kosher. Dunno, there are rules, apparently there was a bad experience once and the NIH got involved.

3. Everyone has their own work to track, but project ownership can be fluid. Another guy should be able to seamlessly take over one of my projects without losing the history, and with 30 seconds or less of over-the-shoulder explanation on how to do it. If an operation requires significant manpage investigation, they'll probably get impatient and just use scp.

4. None of the machines is expected to be on all the time. The network will almost always be available, but we all have laptops, too, so offline work ought to be possible.

5. Speed isn't a big issue; our machines are suave and everything's on a LAN.

Subversion would be OK if we had a designated server that's always on. But we don't. Git has the low-level design figured out a little better than Bazaar, but the plumbing commands are confusing and I couldn't figure out how to make a shared repository temporarily act like it's all centralized, and I worry that a Windows user might come in and spoil the party.

As far as features go, git, hg, bzr and darcs borrow from each other like crazy; the differences are mainly in developer priorities and culture. Bazaar's team cares about documentation and usability above all else, which is what I care about too, here, so that's what I went with.

(I've read several blog posts in which people try git and are absolutely thrilled, but in almost all cases they were previously using CVS or SVN.)

FWIW, I had been using Monotone for a while, but mercurial seems quite a bit simpler in day to day use.

My current offline version control system has been leaving all the files open in TextMate to take advantage of undo/redo. (Horrible I know).

I switched from SVN to git because I needed to work offline for a week, so I gave git a try (initially, I had my project versioned under both systems) and liked it so much I stuck with it.

It was the first distributed VCS I have used. I highly suggest it for personal or small projects, as it supports "dumb storage" and thus you can host a repo anywhere you have ftp or sftp access. It is also handy for working around annoying firewall restrictions where you can't really checkout code the way a centralized system does.

I love DVCS because I get to keep the code on my computer version-controlled, and the power of branching, merging, and cherry-picking is awesome once you get used to it.

I'm pretty new to git though, and I haven't even touched the more advanced features.

using git over subversion because of sane branching / merging / rolling back, history tracking, SPEED, increased redundancy (everybody is backing up the repo!) and local commits.

All projects at work though use Subversion for now, but I am the only developer. (Just makes it easy to revert incase of issues as our system deals with a lot of numbers)

I like Git .. it's very fast and simple to use :)

I do AI, maybe that's the difference. Honestly, apart from utils.lisp, I wouldn't cry much if I suddenly lost all my files. Code is trivial, the important point is in the experience / insights.

I'll try it some day for sure. It's just not that appealing. It was the same with Emacs.

I wrote more about it here, if you'd like convincing:

http://betterexplained.com/articles/a-visual-guide-to-versio...

Then (if you put in on a public server, of course) your work is accessible from anywhere. Run into a friend at Starbucks and want to show him the module you wrote today? Just get into the shell and checkout your repository.

Not only that, it's a perfect record of your project. Occasionally I need to assess the status of the project vis-a-vis some point in the past (for myself when strategizing, for my boss when he needs a report, etc). Being able to look at the commit logs saves time and produces better reports (commit logs don't forget).

So even if you use only the most basic features, you still get an immense benefit from using a VCS. And the hours it's saved me in trivial tasks made it well worth the week it took to hammer down.

But I haven't had any actual advantage from it so far; and any nervousness about playing around with files has shifted across to nervousness about playing around with the repository (I had to delete it and start again a couple of times). Actually, I find doing anything to the repository (reverting, branching etc) terrifying, because I don't really understand what it's going to do, and I could lose everything. If only there was a way to back it all up first... ;-) I'd rather just get on with my actual tasks! Just my experience - so far.

I found the bzr documentation to be a great resource for understanding how DVCS (and even centralized VCS) systems are supposed to work.

http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html

And I like how bzr is willing to act like svn on demand. Setting up a shared repository is easy, other users can pretend they're using a centralized VCS as long as they need to, and when you eventually encounter a situation where distributed development would work better, not much really needs to change -- it's version control with no regrets.

I imagine learning git would probably be much easier if you were already familiar with bzr, since you'd already have a point of reference for most of the operations. The same way C is easier to structure if you already know a higher-level language like Python -- the abstract concepts are already familiar, so it's just a matter of translating them to another language, rather than figuring it all out from scratch in a pricklier environment.

Like many things in the software world, the more you know, the better off you are!

I feel like I need something sometimes but most of the tools above seem a bit complicated and not very intuitive.

How often do you do a bigger change, then realize you still need some pieces of the previous version? Version diff to the rescue!

GitHub is just awesome, especially for open source projects. (of course I say this just as GitHub goes down for the first extended period of time since I started using it)

"git bisect run" is incredibly cool for tracking down when a bug was introduced: http://tlrobinson.net/blog/?p=51

Distributed version control just doesn't get simpler.

Unfortunately, it's not particularly portable and it's not particularly fast. The former I can blame on its dependence on ghc. The latter, I dare not.

You or may not find it helpful. Hope you do.

http://changelog.complete.org/posts/698-If-Version-Control-S...

http://blog.jrock.us/article/Git%20merging%20by%20example.po...

You won't look back.

Before posting, I did Google for polls on the subject of version control and didn't turn up anything (oddly enough, this thread seems to be at the top of the results page):

http://www.google.com/search?hl=en&q="version+control"+poll+site:news.ycombinator.com

Even if I had seen your poll, though, I probably would have posted anyway because I'm interested in getting a feel for how many people use some of the systems that are listed at top besides Git, Mercurial, and Subversion.

For that matter, this one doesn't have plain old RCS, which is what I use.

So, maybe it's a bad choice for a name, but the system itself sounds interesting--it includes a wiki and bug tracking.

subversion for my personal/startup stuff

Using rsync may offer a history of your code, but without any associated semantics, you're dependent on your own memory and grep to actually find out why a change was made. Making commits intentional, and associating them with a particular task, will greatly simplify your code archeology later. Rest assured, some day you will need to figure out why certain decisions were made, and your memory won't be complete (if it was even you who made the decision the first time).

Furthermore, adding a ticketing system from day 1 really helps impose a useful type of discipline onto your process. Work to be done is described in a ticket, and the ticket identifier gets referenced in your commit messages. Much like basic version control discipline, having a record that associates change requests with units of work will help keep you sane down the road.

$ cp -R project testbranch

> then either pull the changes into the trunk or abandon them

diff or rm -rf. And none of the nuisance of explicitly telling the VC system when you're adding, deleting, and renaming files.

Git is pretty good about following renames, moves, and other changes to the underlying filesystem, while still maintaining a proper graph structure to relate revisions to each other. Fast network replication and mirroring is just another benefit, as is the ability to quickly merge changes from multiple branches.

Finally, as another commenter has already suggested, it's really just about establishing good habits as part of your workflow early. It's much like testing: if you start out with a decent test suite, you're much more likely to maintain and use it than you are if you have to overlay testing onto an established project. Similarly, if you have full version history from day 1, things will be much easier further down the road.

I've has some personal projects that were 'moving too fast' for version control, or that I was just playing around with. In every case I ended up losing code because I couldn't remember how I'd done something I'd later removed. And I've never had a project with more than one copy of the codebase -- whether that's a local dev and a production deployment, or two devs -- that didn't end up overwriting code or config at some point.

It's not surprising that version control, largely useful for history, does not appear to be immediately useful for a young project. But young projects become old projects with the same habits and practices. Start with good ones.