15 ms·

You know, I actually expected that the opposite would happen: GitHub would start offering Mercurial hosting. Because Git isn't what attracts most people to Git

You know, I actually expected that the opposite would happen: GitHub would start offering Mercurial hosting. Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community. GitHub is already pretty firmly entrenched in the Git community. I will say, however, that Bitbucket has one primary advantage over GitHub: Unlimited private repositories, with the cost being based on how many collaborators you have. If Bitbucket really promotes this angle, I could see a lot of small development teams moving to Bitbucket, and possibly taking their talent with them. So, if Bitbucket really pushes the "unlimited private repositories" angle, then they could begin taking back market share from GitHub.

zbowling 15y ago
They do support HG in a way. See http://hg-git.github.com/ http://hg-git.github.com/
- gecko 15y ago
  I'll grant that only if you allow me to say that Linux runs Microsoft Office natively due to WINE.
  - zbowling 15y ago
    no. That analogy doesn't fit here. A closer one would be more like Linux supporting FAT32 natively because someone took the time to write proper support for it in an system it wasn't originally designed for (and it works beautifully with almost no corner cases). It may not perform as well but I get to use what I want and still interoperate.
    - eropple 15y ago
      The hg-git abstraction is not very solid. You end up having to "think git" rather than "think hg" and my beef with git isn't in the syntax, it's in git. If I'm going to use hg-git, I might as well use git itself. I don't want to use git; I want to use hg.
      - xpaulbettsx 15y ago
        Why? As a Git fan, someone's perspective on why they prefer Mercurial would be really interesting. What rocks about Mercurial?
        eropple 15y ago
        Your question is difficult to answer in the light in which you intended it, because it doesn't really apply to me. I am not so invested in my source control system to say it "rocks". It works for my purposes and maps nicely to my view of how to handle source code--it's less that Mercurial is awesome, it's that I find Git unpleasant to work with. I find Git over-engineered toward the wrong goals; while I don't doubt the development credentials of the Git developers, I think that too little time has been put into making developers' lives easier. Linus has said previously that speed was a priority for him, and that's great--for kernel sources, I'd definitely put a premium on speed. It appears, however, to come at a cost: Git has long struck me as extremely user-hostile. The documentation may have improved as of late (I haven't checked) but it was absolutely atrocious for a very long time. I find its interface unintuitive and nondiscoverable (and here hg-git could help, were it not for the cognitive dissonance of dealing with one against the other). And its Windows support, even today, is unacceptably poor given that I spend about 40% of my time working there. hg-git addresses some of the more cosmetic issues noted above that I could, if so inclined, deal with myself, but it doesn't really address deeper concerns I have with Git itself. There are also issues of philosophy involved--Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan. (You can rewrite a Mercurial history as well, but it requires going out of your way to do so and is not culturally accepted. "Rebase" exists, via extensions, but nobody uses it. And I much prefer it that way.) To me, Mercurial feels much more like its developers spent a bit more time thinking--looking at how a wider set of developers work, and building something that's comfortable to more people in less time. Git feels like its developers asked no questions at all and started hammering out what made sense to them. Which is fine when it maps to the way you think and the way you work, but it doesn't map to either for me. (I also tend to think that Git wouldn't be nearly as popular had it not been reflexively adopted by everyone and their brother because of Github--this isn't "waah, my tool of choice isn't popular!", but more of a simple observation. I think it succeeds more in spite of itself than anything.)
    - gecko 15y ago
      Fair enough; your analogy is better. But not for the reason you point out. Because FAT32 naming conventions are radically different from Linux', and because it supports radically different directory restrictions, and because it has attributes that Linux doesn't understand, and because it doesn't support permissions, I have to always keep clearly in mind when I've mounted a FAT32 volume v. basically anything else. Yes, I can mount it, and it works just fine until it doesn't. This is my experience with hg-git. Mercurial tags can be moved, Git tags can't be, so I need to keep that in mind. Mercurial signatures don't map to Git ones for obvious reasons or vice-versa, so I can't actually figure out whether a given release was signed by the project author. Mercurial branches lack Git analogs, so I have to remember not to use them. Mercurial bookmarks map to Git branches, so I have to be ready for bookmarks to move in odd ways as Git users work with my hg-git repository. Mercurial's multiple heads per branch have no real analog in Git (they'd be up for garbage collection). This list goes on. When I use hg-git, I have to always keep the Git model in my head, AND keep the Mercurial model in my head, AND keep in mind how those two models interact. This isn't fun, and it's not anything remotely close to transparent. It's amazingly impressive how well hg-git works, but claiming that GitHub supports Mercurial due to hg-git is horribly misleading.
eropple 15y ago
Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community. This sums up my feelings exactly. I'm emphatically not a fan of the Github guys (who seem rather unprofessional), but the community is too big to ignore. I'll probably switch if/when they support hg, unless Atlassian can find a way to encourage a much more robust community in Bitbucket. (And no, Github fans, hg-git is not "support" for hg.)
- burgerbrain 15y ago
  "I'm emphatically not a fan of the Github guys (who seem rather unprofessional)" How so? They're quite snappy with the support in my experience, and handled the firesheep situation much better than most companies.
  - ericb 15y ago
    Not the OP, but I sent a friendly note asking a question that was perhaps a bit dumb--just asking to clarify what one "collaborator" meant to them. The response I got back was a bit rude. Keep in mind my email said I was choosing a subscription plan. As someone who has done support, being rude to people about to purchase your service is even dumber than the question I asked...
    - eropple 15y ago
      I encountered something similar as well with their subscription plans. This was before a friend pointed me to Bitbucket, at which I've been very happy since.
- sandGorgon 15y ago
  A lot of people/companies I know were using Assembla and Beanstalk. I wonder how big a threat this is to them, rather than Github . I notice that Bitbucket hasnt integrated Issues tracker with git. Bitbucket's bug tracking was IMHO much superior to github. Plus Bitbucket doesnt format the README markdown as nicely as Github. EDIT: I notice that I was mistaken. you need to enable bug tracking from the admin tab.
bad_user 15y ago
Git isn't what attracts most people to GitHub I disagree (partly). GitHub is indeed a sort of social-network for developers working on open-source projects, and this makes it really attractive. Their interface is also totally kick-ass and I love them. But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too. I am very excited that Bitbucket is offering Git as an option, as Mercurial for me is not really compelling; not that Git is necessarily better but it's what I know and have absolutely no reason to learn yet-another-tool-that-does-the-same-thing.
- skrebbel 15y ago
  Opposite for me. I never really knew whether to choose Mercurial, Bzr or Git and ended up using Git for everything because of Github.
- trebor 15y ago
  > But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too. Ditto. There's a number of projects that I just won't put online because I'd rather lose than share them. With Bitbucket it looks like I'll be able to stash them privately, for free. I'm totally psyched that Bitbucket has given this good a plan as their base/free package.
  - vog 15y ago
    > There's a number of projects that I just won't put online because I'd rather lose than share them. Assuming that those projects don't generate much revenue for you [1], what's the point of keeping them private? From a political point of view, I always see such projects as a good opportunity to promote Free Software. From an economic point of view, I like to put some pressure on my competitors that way. For really valuable stuff, I'm using strict licenses like GPLv3 or AGPLv3 which ensure that sharing won't result in any disadvantage for me. So I really wonder (as a seriously meant question!) what kind of projects you are talking about. What kind of non/small-revenue project would anyone rather lose than share? [1] Otherwise I'd wonder why you couldn't afford paying GitHub, and also couldn't afford to switch to Mercurial for hosting them on BitBucket for free.
manojlds 15y ago
Exactly, GitHub is to Git as Rails is to Ruby.
snogglethorpe 15y ago
But look at it this way: What would github gain by adding mercurial support? They're insanely popular and becoming more so by the minute, and their biggest problems probably have to do with managing growth, not lack of users. With git itself becoming increasingly popular, there's absolutely no sense that git will be a limiting factor any time in the future. They clearly do recognize the long-term advantages in improving the usability of git, and have been making moves in that direction (iphone client, increasing the functionality of their web interface, some interaction on the git dev list), but hg's purported UI advantages are tenuous at best, and it seems a much surer bet to consolidate their position and improve git instead of investing a lot of effort in supporting hg, which would only _dilute_ their position.

zbowling 15y ago

They do support HG in a way. See http://hg-git.github.com/ http://hg-git.github.com/

gecko 15y ago
I'll grant that only if you allow me to say that Linux runs Microsoft Office natively due to WINE.
- zbowling 15y ago
  no. That analogy doesn't fit here. A closer one would be more like Linux supporting FAT32 natively because someone took the time to write proper support for it in an system it wasn't originally designed for (and it works beautifully with almost no corner cases). It may not perform as well but I get to use what I want and still interoperate.
  - eropple 15y ago
    The hg-git abstraction is not very solid. You end up having to "think git" rather than "think hg" and my beef with git isn't in the syntax, it's in git. If I'm going to use hg-git, I might as well use git itself. I don't want to use git; I want to use hg.
    - xpaulbettsx 15y ago
      Why? As a Git fan, someone's perspective on why they prefer Mercurial would be really interesting. What rocks about Mercurial?
      - eropple 15y ago
        Your question is difficult to answer in the light in which you intended it, because it doesn't really apply to me. I am not so invested in my source control system to say it "rocks". It works for my purposes and maps nicely to my view of how to handle source code--it's less that Mercurial is awesome, it's that I find Git unpleasant to work with. I find Git over-engineered toward the wrong goals; while I don't doubt the development credentials of the Git developers, I think that too little time has been put into making developers' lives easier. Linus has said previously that speed was a priority for him, and that's great--for kernel sources, I'd definitely put a premium on speed. It appears, however, to come at a cost: Git has long struck me as extremely user-hostile. The documentation may have improved as of late (I haven't checked) but it was absolutely atrocious for a very long time. I find its interface unintuitive and nondiscoverable (and here hg-git could help, were it not for the cognitive dissonance of dealing with one against the other). And its Windows support, even today, is unacceptably poor given that I spend about 40% of my time working there. hg-git addresses some of the more cosmetic issues noted above that I could, if so inclined, deal with myself, but it doesn't really address deeper concerns I have with Git itself. There are also issues of philosophy involved--Git requires you to accept certain behaviors and the cultural encouragement of same, e.g. rewritable history, of which I'm very much not a fan. (You can rewrite a Mercurial history as well, but it requires going out of your way to do so and is not culturally accepted. "Rebase" exists, via extensions, but nobody uses it. And I much prefer it that way.) To me, Mercurial feels much more like its developers spent a bit more time thinking--looking at how a wider set of developers work, and building something that's comfortable to more people in less time. Git feels like its developers asked no questions at all and started hammering out what made sense to them. Which is fine when it maps to the way you think and the way you work, but it doesn't map to either for me. (I also tend to think that Git wouldn't be nearly as popular had it not been reflexively adopted by everyone and their brother because of Github--this isn't "waah, my tool of choice isn't popular!", but more of a simple observation. I think it succeeds more in spite of itself than anything.)
  - gecko 15y ago
    Fair enough; your analogy is better. But not for the reason you point out. Because FAT32 naming conventions are radically different from Linux', and because it supports radically different directory restrictions, and because it has attributes that Linux doesn't understand, and because it doesn't support permissions, I have to always keep clearly in mind when I've mounted a FAT32 volume v. basically anything else. Yes, I can mount it, and it works just fine until it doesn't. This is my experience with hg-git. Mercurial tags can be moved, Git tags can't be, so I need to keep that in mind. Mercurial signatures don't map to Git ones for obvious reasons or vice-versa, so I can't actually figure out whether a given release was signed by the project author. Mercurial branches lack Git analogs, so I have to remember not to use them. Mercurial bookmarks map to Git branches, so I have to be ready for bookmarks to move in odd ways as Git users work with my hg-git repository. Mercurial's multiple heads per branch have no real analog in Git (they'd be up for garbage collection). This list goes on. When I use hg-git, I have to always keep the Git model in my head, AND keep the Mercurial model in my head, AND keep in mind how those two models interact. This isn't fun, and it's not anything remotely close to transparent. It's amazingly impressive how well hg-git works, but claiming that GitHub supports Mercurial due to hg-git is horribly misleading.

eropple 15y ago

Because Git isn't what attracts most people to GitHub. It's the sheer fact that GitHub is frickin' HUGE and has lots of people who will show up, fork your project, and send you a pull request. I love Bitbucket, but honestly if GitHub added Mercurial support I would probably move all the way to GitHub because of the size of the community. This sums up my feelings exactly. I'm emphatically not a fan of the Github guys (who seem rather unprofessional), but the community is too big to ignore. I'll probably switch if/when they support hg, unless Atlassian can find a way to encourage a much more robust community in Bitbucket. (And no, Github fans, hg-git is not "support" for hg.)

burgerbrain 15y ago
"I'm emphatically not a fan of the Github guys (who seem rather unprofessional)" How so? They're quite snappy with the support in my experience, and handled the firesheep situation much better than most companies.
- ericb 15y ago
  Not the OP, but I sent a friendly note asking a question that was perhaps a bit dumb--just asking to clarify what one "collaborator" meant to them. The response I got back was a bit rude. Keep in mind my email said I was choosing a subscription plan. As someone who has done support, being rude to people about to purchase your service is even dumber than the question I asked...
  - eropple 15y ago
    I encountered something similar as well with their subscription plans. This was before a friend pointed me to Bitbucket, at which I've been very happy since.
sandGorgon 15y ago
A lot of people/companies I know were using Assembla and Beanstalk. I wonder how big a threat this is to them, rather than Github . I notice that Bitbucket hasnt integrated Issues tracker with git. Bitbucket's bug tracking was IMHO much superior to github. Plus Bitbucket doesnt format the README markdown as nicely as Github. EDIT: I notice that I was mistaken. you need to enable bug tracking from the admin tab.

bad_user 15y ago

Git isn't what attracts most people to GitHub I disagree (partly). GitHub is indeed a sort of social-network for developers working on open-source projects, and this makes it really attractive. Their interface is also totally kick-ass and I love them. But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too. I am very excited that Bitbucket is offering Git as an option, as Mercurial for me is not really compelling; not that Git is necessarily better but it's what I know and have absolutely no reason to learn yet-another-tool-that-does-the-same-thing.

skrebbel 15y ago
Opposite for me. I never really knew whether to choose Mercurial, Bzr or Git and ended up using Git for everything because of Github.
trebor 15y ago
> But for my private projects GitHub is totally useless and also expensive, which is why I have been hosting my own Git repo on an instance that I own - it's pretty easy to setup too. Ditto. There's a number of projects that I just won't put online because I'd rather lose than share them. With Bitbucket it looks like I'll be able to stash them privately, for free. I'm totally psyched that Bitbucket has given this good a plan as their base/free package.
- vog 15y ago
  > There's a number of projects that I just won't put online because I'd rather lose than share them. Assuming that those projects don't generate much revenue for you [1], what's the point of keeping them private? From a political point of view, I always see such projects as a good opportunity to promote Free Software. From an economic point of view, I like to put some pressure on my competitors that way. For really valuable stuff, I'm using strict licenses like GPLv3 or AGPLv3 which ensure that sharing won't result in any disadvantage for me. So I really wonder (as a seriously meant question!) what kind of projects you are talking about. What kind of non/small-revenue project would anyone rather lose than share? [1] Otherwise I'd wonder why you couldn't afford paying GitHub, and also couldn't afford to switch to Mercurial for hosting them on BitBucket for free.

manojlds 15y ago

Exactly, GitHub is to Git as Rails is to Ruby.

snogglethorpe 15y ago

But look at it this way: What would github gain by adding mercurial support? They're insanely popular and becoming more so by the minute, and their biggest problems probably have to do with managing growth, not lack of users. With git itself becoming increasingly popular, there's absolutely no sense that git will be a limiting factor any time in the future. They clearly do recognize the long-term advantages in improving the usability of git, and have been making moves in that direction (iphone client, increasing the functionality of their web interface, some interaction on the git dev list), but hg's purported UI advantages are tenuous at best, and it seems a much surer bet to consolidate their position and improve git instead of investing a lot of effort in supporting hg, which would only _dilute_ their position.