4 ms·
I never get these Git vs. Mercurial debates. I don't see why they matter. Pick something you like & are comfortable with & can use well - and then learn that to
by oconnor0 17y ago
I never get these Git vs. Mercurial debates. I don't see why they matter. Pick something you like & are comfortable with & can use well - and then learn that tool well.
Linus certainly doesn't care if you think Mercurial's better than Git. He doesn't agree. He wrote a tool to help him manage the Linux kernel source trees, something it does well. His goals never have been making the most elegant or intelligent software, but making good software that works. And it's a strategy that's succeeded.
And the Mercurial devs probably think the same regarding Git.
As an aside, I wonder what would have happened had not Linus popularized distributed version control systems. I doubt we'd even be having this discussion. I certainly hadn't been exposed before hearing about the BitKeeper debacle.
- tdavis 17y agoExactly. I am a huge Python fan and have contemplated giving Mercurial a go just because I know I could hack it myself if need be and that'd be cool. But I've gotten to the point where I know my way around Git well enough that I can't justify it. Besides familiarity with the commands, I've also gotten used to the workflow, which I'm sure differs under Mercurial.
- ubernostrum 17y ago"I've also gotten used to the workflow, which I'm sure differs under Mercurial." Yes and no. The workflow for managing branches is different, because you usually just clone an hg repo to do a branch, and then merge as needed. The workflow for more complex things isn't quite as different as most people seem to think, though; mainly the difference is that in hg the answer is "use a patch queue". Operations on patch queues are somewhat lower level than, say, git's rebase, but all the power is still there (and there's a rebase extension which will let you do it all in one go if that's your thing). What's been interesting to me is seeing the evolution of the "popular" git workflow over time. Originally, people hyped things like rebasing and editing commit history, but gradually the emphasis has shifted away from that and the best practices have solidified around using those features only when they're necessary, which is much less often than a lot of folks originally believed. And, amusingly, that's very close to the way hg has always been used: you can do lots of fancy stuff, but you should have a good reason for doing so (and should typically never do so after you've pushed to other folks or they've pulled from you).