5 ms·

Codeplex donates $25,000 to Mercurial

walkon 16y ago
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/
- KTamas 16y ago
  Except Fog Creek is a gold sponsor already: http://mercurial.selenic.com/sponsors/ http://mercurial.selenic.com/sponsors/
  - walkon 16y ago
    Ah, very good, that's why I said, "perhaps they have" - thanks for the link.
  - benatkin 16y ago
    At least $20K. Impressive.
paulitex 16y ago
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.

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/

KTamas 16y ago
Except Fog Creek is a gold sponsor already: http://mercurial.selenic.com/sponsors/ http://mercurial.selenic.com/sponsors/
- walkon 16y ago
  Ah, very good, that's why I said, "perhaps they have" - thanks for the link.
- benatkin 16y ago
  At least $20K. Impressive.

paulitex 16y ago

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.