Codeplex donates $25,000 to Mercurial
blogs.msdn.com
blogs.msdn.com
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.)
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.
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 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.
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.
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.
An alternative solution is to use BitBucket and mirror everything to GitHub: http://hgtip.com/tips/advanced/2009-11-09-create-a-git-mirro...
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.
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.
Or is Github the Steve-Jobs of revision control ? "You dont need that"