Codeplex donates $25,000 to Mercurial(blogs.msdn.com)
blogs.msdn.com
Codeplex donates $25,000 to Mercurial
http://blogs.msdn.com/b/codeplex/archive/2010/09/06/codeplex-com-donates-25-000-to-mercurial-project.aspx
26 comments
Is there anything specific that you think Bitbucket is missing or lagging behind in compared to Github?
What is it about HG you prefer? Git and HG seem pretty comparable as far as features go but github seems to have all the momentum.
I'm not the OP, but I'll give my reasoning for preferring Mercurial: its CLI has commands that each do one thing instead of commands that have options to do anything.
For example: `git checkout` can change the contents of files without changing where you are in the DAG, change where you are in the DAG, and even create a new branch. In Mercurial you'd use three separate commands for these things: `hg revert`, `hg update`, and `hg branch`.
The problem with git's approach is this: making every command very flexible through options means that you need to document the interaction of all these options in the man pages. That makes the documentation for each command harder to read, especially when you're in the middle of trying to get something done with a project and just want to do something quickly.
For a real example, look at the help for the two SCMs' commands for changing the contents of a file:
When you combine the help for the equivalent Mercurial commands it's still more succinct than git's help, because splitting individual actions into different commands means you don't have to document interactions between options:
For example: `git checkout` can change the contents of files without changing where you are in the DAG, change where you are in the DAG, and even create a new branch. In Mercurial you'd use three separate commands for these things: `hg revert`, `hg update`, and `hg branch`.
The problem with git's approach is this: making every command very flexible through options means that you need to document the interaction of all these options in the man pages. That makes the documentation for each command harder to read, especially when you're in the middle of trying to get something done with a project and just want to do something quickly.
For a real example, look at the help for the two SCMs' commands for changing the contents of a file:
$ (hg help revert) | wc -l
47
$ (git help checkout) | wc -l
276
When you combine the help for the equivalent Mercurial commands it's still more succinct than git's help, because splitting individual actions into different commands means you don't have to document interactions between options:
$ (hg help revert; hg help update; hg help branch) | wc -l
113
$ (git help checkout) | wc -l
276
I learned Mercurial first and found the vast majority of its commands to be highly intuitive for the 4 core actions of a distributed version control system
1) Check-pointing code 2) Jumping back (or sideways) in time 3) Sending code to others 4) Receiving code from others
However, once I really understood the distributed version control model, I found myself thinking in terms of the DAG and wanting more control over it. I started viewing my version control system as a tool for more than just version control. I started viewing it as a tool for understanding and communicating about my code. I started using it as a tool to manipulate my code.
Then, for one small project, I tried Git. It drove me NUTS for about a week. I was going to smash things. I was so angry about it using stupid cryptic terms for simple things. I was annoyed by the complexity of overloaded, highly flexible commands. But once I translated the vocabulary, the commands stopped seeming so complex. Instead, they seemed like a reasonable abstractions. Each of the sub-operations they can perform are really just specializations of one kind of operation. It became second nature. I started doing swiss-army-knife voodoo with Git that Mercurial could only accomplish with a giant pile of half-baked plugins, blood, sweat, and tears.
Now, I only use Git.
tldr: Git is a more abstract, more powerful tool than any mere version control system. This is only something you come to appreciate with experience.
1) Check-pointing code 2) Jumping back (or sideways) in time 3) Sending code to others 4) Receiving code from others
However, once I really understood the distributed version control model, I found myself thinking in terms of the DAG and wanting more control over it. I started viewing my version control system as a tool for more than just version control. I started viewing it as a tool for understanding and communicating about my code. I started using it as a tool to manipulate my code.
Then, for one small project, I tried Git. It drove me NUTS for about a week. I was going to smash things. I was so angry about it using stupid cryptic terms for simple things. I was annoyed by the complexity of overloaded, highly flexible commands. But once I translated the vocabulary, the commands stopped seeming so complex. Instead, they seemed like a reasonable abstractions. Each of the sub-operations they can perform are really just specializations of one kind of operation. It became second nature. I started doing swiss-army-knife voodoo with Git that Mercurial could only accomplish with a giant pile of half-baked plugins, blood, sweat, and tears.
Now, I only use Git.
tldr: Git is a more abstract, more powerful tool than any mere version control system. This is only something you come to appreciate with experience.
Can you provide a concrete example of DAG editing which you had trouble doing with Mercurial?
From things as simple as "git stash" to anything you'd use Mercurial's MQ extension for and beyond. Also, the Index, a concept which I initially wrote off as a frustrating extra step, turns out to be super useful for moving around chunks of code quickly.
TL;DR version: Git's decision to make its CLI's commands very flexible results in painful documentation, so I perfer Mercurial.
I guess that jibes with my own experience. I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.
Github seems like a real juggernaut now though. So many job postings now specifically ask for github urls, although I suppose a bitbucket link would probably be ok.
I guess that jibes with my own experience. I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.
Github seems like a real juggernaut now though. So many job postings now specifically ask for github urls, although I suppose a bitbucket link would probably be ok.
> I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.
Yeah that's what grates me about Git: apparently, unless you're willing to learn all of it from the implementation details up (which I am not as I have absolutely no interest in implementing my own DVCS) you will forever be limited to rote-learned "recipes" because the command-line interface makes no sense in and of itself, it only makes sense if you understand how it relates to Git's implementation details.
I'm sure somebody will chime in with "well make your own CLI then" or "other people have built new porcelains and they have not taken off". Of course that won't work, for two reasons:
1. To build my own porcelain, I'd have to learn all of Git's implementation details. See above
2. People who build their own porcelains have to do it as well, and by the time they're done learning... they don't need a separate porcelain anymore. They might not even realize why they were trying to do it in the first place. And so they leave their project in a mostly-broken state and go on with their life, and the next guy comes around and builds his own from scratch.
Yeah that's what grates me about Git: apparently, unless you're willing to learn all of it from the implementation details up (which I am not as I have absolutely no interest in implementing my own DVCS) you will forever be limited to rote-learned "recipes" because the command-line interface makes no sense in and of itself, it only makes sense if you understand how it relates to Git's implementation details.
I'm sure somebody will chime in with "well make your own CLI then" or "other people have built new porcelains and they have not taken off". Of course that won't work, for two reasons:
1. To build my own porcelain, I'd have to learn all of Git's implementation details. See above
2. People who build their own porcelains have to do it as well, and by the time they're done learning... they don't need a separate porcelain anymore. They might not even realize why they were trying to do it in the first place. And so they leave their project in a mostly-broken state and go on with their life, and the next guy comes around and builds his own from scratch.
>> I've learned how to use git not so much from intuition but memorization of what all the commands do and how they interact.
>Yeah that's what grates me about Git: apparently, unless you're willing to learn all of it from the implementation details up (which I am not as I have absolutely no interest in implementing my own DVCS) you will forever be limited to rote-learned "recipes" because the command-line interface makes no sense in and of itself, it only makes sense if you understand how it relates to Git's implementation details.
That's what I thought, too. After I had typed in one meaningless magic incantation too many, I bit the bullet and dug into the source to understand _why_ the same command was used for three completely unrelated goals (I can't remember what the actual command was, probably reset or checkout).
To my dismay the goals were completely unrelated even in the source code. The command parsed its command line and took different code paths -- not even working on the same data structures -- depending on its arguments.
It's of course possible that I didn't read the code well enough, but even at the source code level it is not always _obvious_ why Git's commands have multiple roles, and why different commands can be used to reach the same goal. My first thought was that at some point it just must have been slightly easier to add a new switch to an existing command than to add a new command.
Needless to say, I'm now a happy user of Mercurial (and its wonderful pbranch extension, among others). My mental model of Mercurial's workings might not be completely accurate, but so far it's been consistent enough to never surprise me, and the commands that I use make intuitive sense within that model.
>Yeah that's what grates me about Git: apparently, unless you're willing to learn all of it from the implementation details up (which I am not as I have absolutely no interest in implementing my own DVCS) you will forever be limited to rote-learned "recipes" because the command-line interface makes no sense in and of itself, it only makes sense if you understand how it relates to Git's implementation details.
That's what I thought, too. After I had typed in one meaningless magic incantation too many, I bit the bullet and dug into the source to understand _why_ the same command was used for three completely unrelated goals (I can't remember what the actual command was, probably reset or checkout).
To my dismay the goals were completely unrelated even in the source code. The command parsed its command line and took different code paths -- not even working on the same data structures -- depending on its arguments.
It's of course possible that I didn't read the code well enough, but even at the source code level it is not always _obvious_ why Git's commands have multiple roles, and why different commands can be used to reach the same goal. My first thought was that at some point it just must have been slightly easier to add a new switch to an existing command than to add a new command.
Needless to say, I'm now a happy user of Mercurial (and its wonderful pbranch extension, among others). My mental model of Mercurial's workings might not be completely accurate, but so far it's been consistent enough to never surprise me, and the commands that I use make intuitive sense within that model.
To cageface (I can't seem to reply to your comment for some reason):
An alternative solution is to use BitBucket and mirror everything to GitHub: http://hgtip.com/tips/advanced/2009-11-09-create-a-git-mirro...
An alternative solution is to use BitBucket and mirror everything to GitHub: http://hgtip.com/tips/advanced/2009-11-09-create-a-git-mirro...
SCM preference is very much a religious debate, and I don't really want to start one... but my instinct would be to say the interface is a lot more intuitive than git. Also, it's what I know. I worked on Mercurial as part of a school-sponsered thing similar to GSOC, so my competency is pretty high with hg, while git tends to get me in trouble and generally scares me. I know I could probably learn my way out of this, but it's the honest answer.
> while git tends to get me in trouble
Likewise. On the other hand, once you've blown off your leg and if you have time to waste (your probably do, seeing as you're now missing a leg) it does give you tools to sew the stuff back together (see reflog). It's much easier to wedge your repository in Git (for reasons you don't understand after invoking a command which seemed straightforward at the time), but in my experience Mercurial doesn't Mercurial doesn't always provide the tools to dig you out of your holes.
What that says about each VCS, you'll be the judge.
Likewise. On the other hand, once you've blown off your leg and if you have time to waste (your probably do, seeing as you're now missing a leg) it does give you tools to sew the stuff back together (see reflog). It's much easier to wedge your repository in Git (for reasons you don't understand after invoking a command which seemed straightforward at the time), but in my experience Mercurial doesn't Mercurial doesn't always provide the tools to dig you out of your holes.
What that says about each VCS, you'll be the judge.
Let's agree that Git has more momentum, and GitHub the best hosting interface available. The main reason to choose Mercurial in the face of this is that it's command line interface seems far more well thought out than Git's. Given how much time you spend interacting with the repository on the command-line, this is hugely significant.
why not http://hg-git.github.com/? hg commands on a git repo.
When we wanted to begin a new project - our choice of SCM and forge went hand-in-hand.
The big plus of hg is that it will work on all platforms - Win (yup), OSX, Linux The big plus of bitbucket is that it does not limit the number of users you can add to your project - github's paid plans limit number of users.
I'm sure github has a hell of a lot of features, but we dont use most of them - what we do use, the pricing model of bitbucket makes more sense.
The big plus of hg is that it will work on all platforms - Win (yup), OSX, Linux The big plus of bitbucket is that it does not limit the number of users you can add to your project - github's paid plans limit number of users.
I'm sure github has a hell of a lot of features, but we dont use most of them - what we do use, the pricing model of bitbucket makes more sense.
The user limits are a good thing: Let teams and individuals fork the projects. Favor more, smaller projects of better factored code, each with key trusted contributors. If your teams are large enough, you should have lieutenants performing code reviews upon pull request. Embrace the distributed model.
But what limit is a good limit?
I might not be inclined to the same number philosophy that github forces on me.
Or is Github the Steve-Jobs of revision control ? "You dont need that"
Or is Github the Steve-Jobs of revision control ? "You dont need that"
Whatever it is, it's probably lower than what GitHub provides. I mean, some of the largest and most promenant open source projects (with the most contributors) live in GitHub. For example, I read that Ruby on Rails 3 "consists of almost 4,000 commits by more than 250 authors".
Our organization plans support unlimited teams/users: http://github.com/plans
Git works now on Windows, too.
I'm genuinely curious - what's the main reason you discount codeplex? It doesn't have any restrictions on the languages/frameworks/target platforms etc, and you can choose any license you want. Is it that Microsoft just have a lot of banked hate-debt?
Perhaps they have or will soon, but you'd think Fog Creek (Joel Spolsky) would want to donate a bit as well since Kiln revolves around Mercurial:
http://www.fogcreek.com/kiln/
http://www.fogcreek.com/kiln/
Except Fog Creek is a gold sponsor already: http://mercurial.selenic.com/sponsors/
It's a genuine problem (for me at least) when starting a new project - bitbucket (-) and Mercurial (+) or github (+) and git (-). If anyone from github is reading this - please consider first-class Mercurial support. It would almost definitely be easier for you to do this than for bitbucket to make up the gap.
(I know lots of people prefer git, but Github already has that market pretty cornered. There is an opportunity among those who prefer hg.)