4 ms·

Fantastic. Though what Mercurial needs even more than Matt's full time attention is a really good forge. Bitbucket just really doesn't hold a candle to Github (

Fantastic. Though what Mercurial needs even more than Matt's full time attention is a really good forge. Bitbucket just really doesn't hold a candle to Github (and codeplex is pretty unattractive for anyone not a microsoft dev). 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.)

cageface 16y ago
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.
- paulitex 16y ago
  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.
  - masklinn 16y ago
    > 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.
- stevelosh 16y ago
  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: $ (hg help revert) | wc -l 47 $ (git help checkout) | wc -l 276 Some might say: "But `git checkout` can do so much more than `hg revert`!" That's absolutely true. However, every time I want to look up how to revert file contents I need to wade through hundreds of irrelevant lines in git's documentation. When I'm using Mercurial I say "Well, I know I need to use `hg revert`, let's just look at those 47 lines of help and find out what exactly I need." 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 TL;DR version: Git's decision to make its CLI's commands very flexible results in painful documentation, so I perfer Mercurial.
  - cageface 16y ago
    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.
    - masklinn 16y ago
- lars512 16y ago
  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.
bfung 16y ago
why not http://hg-git.github.com/ http://hg-git.github.com/? hg commands on a git repo.
brodie 16y ago
Is there anything specific that you think Bitbucket is missing or lagging behind in compared to Github?
sandGorgon 16y ago
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.
- snprbob86 16y ago
  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.
  - sandGorgon 16y ago
    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"
    - snprbob86 16y ago
      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".
- eru 16y ago
  Git works now on Windows, too.
- pjhyett 16y ago
  Our organization plans support unlimited teams/users: http://github.com/plans http://github.com/plans
josephcooney 16y ago
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?

cageface 16y ago

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.

paulitex 16y ago
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.
- masklinn 16y ago
  > 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.
stevelosh 16y ago
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: $ (hg help revert) | wc -l 47 $ (git help checkout) | wc -l 276 Some might say: "But `git checkout` can do so much more than `hg revert`!" That's absolutely true. However, every time I want to look up how to revert file contents I need to wade through hundreds of irrelevant lines in git's documentation. When I'm using Mercurial I say "Well, I know I need to use `hg revert`, let's just look at those 47 lines of help and find out what exactly I need." 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 TL;DR version: Git's decision to make its CLI's commands very flexible results in painful documentation, so I perfer Mercurial.
- cageface 16y ago
  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.
  - masklinn 16y ago
lars512 16y ago
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.

bfung 16y ago

why not http://hg-git.github.com/ http://hg-git.github.com/? hg commands on a git repo.

brodie 16y ago

Is there anything specific that you think Bitbucket is missing or lagging behind in compared to Github?

sandGorgon 16y ago

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.

snprbob86 16y ago
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.
- sandGorgon 16y ago
  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"
  - snprbob86 16y ago
    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".
eru 16y ago
Git works now on Windows, too.
pjhyett 16y ago
Our organization plans support unlimited teams/users: http://github.com/plans http://github.com/plans

josephcooney 16y ago

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?