Hacker News Reader

Comment by manuletroll | Hacker News Reader

While I'm all for abandoning old and often awful VCSs, I do think there's room for some diversity. Git's not really my thing, and I'm happy to be able to use an alternative. Most DVCSs work in very similar ways, and for standard use, I don't think there is a huge learning curve for someone switching between git and mercurial, for instance. Some other tools have their own benefits, like fossil with its nice integrated web project management features. All in all, I'd be quite sad to see only git everywhere.

View on HN

Obviously no one should be forcing you to use what you don't like. But I don't quite understand that reasoning. Except for rare circumstances, SCM use isn't a "personal" activity. It's not about what you pick for yourself, it's about what everyone collectively chooses to use for collaboration.

And in that sense, there are really high costs to variety. Imagine a world where you need to be fluent not just in whichever two of RCS/CVS/subversion/git are currently en vogue, but also mercurial, SCCS, bitkeeper, Perforce, ClearCase, etc... That's a mess.

So sure, git might not be "your thing", but I strongly suspect you'd still prefer a git-only world to one where every project you want to tinker with uses a different SCM.

By "I don't like git", I mostly meant that git's not my favourite VCS, not that I'd refuse to use it or actively advocate against it or anything. I'll always use what's most convenient for the team as a whole. The point was that when I have a choice, I'd rather use mercurial than git. But really, those two are really close. There's even a plugin that lets you use interact with git repos from mercurial.

And of course I can only agree with your last sentence, a bit of standardization is a good thing.

> While I'm all for abandoning old and often awful VCSs, I do think there's room for some diversity.

So do I. I just think that it will be nice should there come a day where knowing git will allow you to deal with the majority of the positions out there. I do not believe git is a 100% fit for all organizations. I do, however, believe git is flexible enough to be a fit for, say, 80-90% of them.

I think git will become a de facto standard. Like all such things, though, there will be alternatives available and in active use.

I see your point, and I'd much rather see git become a standard rather than a Visual Source Safe clone.

At work I chose (yeah, there was no VCS in use before that) mercurial mainly because we're a small .NET shop, and a nice GUI like TortoiseHg is a big selling point when you're trying to encourage people to use such a tool. There are actually lots of developers who just <i>hate</i> using a CLI. And I don't know how things have evolved, but git was not known to be very windows-friendly two years ago, even apart from the GUI thing.

How is TortioseGIT deficient compared to TortoiseHg? I would think at this point, they are sort of equivalent, but I don't have experience with Mercurial.

Well last I checked (which is now quite a while back) it seemed far less polished and stable. However I'd probably have to try it again, according to what I can see on the project's page it seems to have improved a lot.

From my recent experience (past month or so), TortoiseHG is definitely more polished than TortoiseGit. The thing I miss the most is the "Workbench", a single window that contains everything you'd need to do (commit, view history, sync, etc).

Reply on news.ycombinator.com