7 ms·

> this is an unfortunate blow to Python Just as unfortunate as how Python turned its back to Mercurial

by etanol 9y ago

yeukhon 9y ago
You are referring to https://www.python.org/dev/peps/pep-0512 https://www.python.org/dev/peps/pep-0512 aren't you?
- microcolonel 9y ago
  Such a petty and childish thing to be upset by. If Mercurial is soo great, then surely nobody would switch to git. Mercurial's extensibility has served some people, but in large part people prefer to work with git today. If that's what constitutes a betrayal, I don't see how there was much of a relationship to betray. Mercurial, Bazaar, Darcs, CVS, and even Subversion are all now barriers to entry for a project. Git has won the vast majority of mindshare and good will by being straightforward, ubiquitous, and well supported.
  - akavel 9y ago
    People are switching to git because of popularity and GitHub, regardless if it's technologically superior. Not always the better technology wins, often rather "just" the more popular one.
    - microcolonel 9y ago
      Sounds like a cop-out to me. GitHub and GitLab are strengths of Git, just as L3 networks, Verizon, CloudFlare, AWS, and Akamai are all strengths of TCP.
  - muxator 9y ago
    Yes, git won. This does not mean that mercurial is not highly ergonomic, equally powerful, with a very ordered and dynamic codebase, and a sane community. Edit: and I keep wondering what the panorama would have been like if we had hghub instead of github.
    - yeukhon 9y ago
      There is, Bitbucket was exclusively Hg before Bitbucket saw Git's popularity. This is my opinion: Bitbucket is like the new Sourceforge. I'd be interested to see a survey on Hg and Git usage today.
      - glandium 9y ago
        IIRC from when I looked ~2 years ago, > 80% of new repositories on bitbucket were using git. (and that's a conservative estimate, because I'm not entirely sure whether it clearly was over 90% or not, but it might (likely) have been).
    - microcolonel 9y ago
      > I keep wondering what the panorama would have been like if we had HgHub instead of GitHub. Yeah, I think that the Linux process and jargon both came along for the ride with Git, so it would probably be even more different than you think.
  - bsder 9y ago
    > Git has won the vast majority of mindshare and good will by being straightforward, ubiquitous, and well supported. Thanks for a good laugh. The sheer volume of "No the REALLY right way to think about git's totally brain damaged use of source control concepts. This time we mean it." tutorials shows that "ubiquitous" is true but "straightforward" and "well supported" are a lie. But you are correct. The vast majority of coders have decided on git. I will happily sit over here on Mercurial while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago. The Mercurial->git gateways are now quite good and I can do my development in Mercurial and transfer it to git at infrequent intervals. It's not like git people want to see all my intermediate commits anyway--that's the whole point of "rebase" after all.
    - microcolonel 9y ago
      > while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago I sense a lot of resentment in this statement, but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I could understand being frustrated trying to jump right into it, especially with the interface as of the mid-late oughts, but it's fairly straightforward these days. The defaults make sense, and the built-in tools are consistent and plentiful. I doubt I could compose a correct filter-branch from memory, but I don't even think I could find an example for Mercurial, and I doubt the manpage would be as helpful.
      - bsder 9y ago
        > but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I will be happy to call you the next time one of my devs does something that causes git to wedge itself into one of those states. It happens about every 2 weeks--and I suspect that it happens more frequently than that. Normally I can unwedge git after reading approximately 10 git pages all claiming to fix my problem (they don't but they probably point me at the brain-damaged command I need). Most of the time ... about once every 3 months everything fails and we have to pull a backup. Fortunately, the devs have now been brainwashed to rsync the repository on at least a daily basis and always before they do anything besides a basic checkout or commit. But, hey, they're using git, and it's what everybody else uses. As someone who uses Mercurial and does some pretty hairy stuff with it, I have never put the system into a wedged state. NEVER. The only time I saw a Mercurial repo get wedged was when the underlying filesystem barfed on itself. Yeah, I'm a touch sore about this because I regularly get to fix problems that WOULD NOT EXIST if the team was in Mercurial instead of git. However, as a manager who likes to think of himself as "good", I cannot force tools on a team unless they actually do measurable damage. I also get sore with the "Well, if you only understood the git model..." I DO understand the git model--much to my horror. The problem is that while a newbie can learn the Mercurial model in about 60 seconds and be productive the git model takes about 60 months to learn and they will still regularly footgun themselves.
  - arunc 9y ago
    git won because of GitHub and StackOverflow.

> this is an unfortunate blow to Python Just as unfortunate as how Python turned its back to Mercurial

by etanol 9y ago

> this is an unfortunate blow to Python Just as unfortunate as how Python turned its back to Mercurial

yeukhon 9y ago

You are referring to https://www.python.org/dev/peps/pep-0512 https://www.python.org/dev/peps/pep-0512 aren't you?

microcolonel 9y ago
Such a petty and childish thing to be upset by. If Mercurial is soo great, then surely nobody would switch to git. Mercurial's extensibility has served some people, but in large part people prefer to work with git today. If that's what constitutes a betrayal, I don't see how there was much of a relationship to betray. Mercurial, Bazaar, Darcs, CVS, and even Subversion are all now barriers to entry for a project. Git has won the vast majority of mindshare and good will by being straightforward, ubiquitous, and well supported.
- akavel 9y ago
  People are switching to git because of popularity and GitHub, regardless if it's technologically superior. Not always the better technology wins, often rather "just" the more popular one.
  - microcolonel 9y ago
    Sounds like a cop-out to me. GitHub and GitLab are strengths of Git, just as L3 networks, Verizon, CloudFlare, AWS, and Akamai are all strengths of TCP.
- muxator 9y ago
  Yes, git won. This does not mean that mercurial is not highly ergonomic, equally powerful, with a very ordered and dynamic codebase, and a sane community. Edit: and I keep wondering what the panorama would have been like if we had hghub instead of github.
  - yeukhon 9y ago
    There is, Bitbucket was exclusively Hg before Bitbucket saw Git's popularity. This is my opinion: Bitbucket is like the new Sourceforge. I'd be interested to see a survey on Hg and Git usage today.
    - glandium 9y ago
      IIRC from when I looked ~2 years ago, > 80% of new repositories on bitbucket were using git. (and that's a conservative estimate, because I'm not entirely sure whether it clearly was over 90% or not, but it might (likely) have been).
  - microcolonel 9y ago
    > I keep wondering what the panorama would have been like if we had HgHub instead of GitHub. Yeah, I think that the Linux process and jargon both came along for the ride with Git, so it would probably be even more different than you think.
- bsder 9y ago
  > Git has won the vast majority of mindshare and good will by being straightforward, ubiquitous, and well supported. Thanks for a good laugh. The sheer volume of "No the REALLY right way to think about git's totally brain damaged use of source control concepts. This time we mean it." tutorials shows that "ubiquitous" is true but "straightforward" and "well supported" are a lie. But you are correct. The vast majority of coders have decided on git. I will happily sit over here on Mercurial while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago. The Mercurial->git gateways are now quite good and I can do my development in Mercurial and transfer it to git at infrequent intervals. It's not like git people want to see all my intermediate commits anyway--that's the whole point of "rebase" after all.
  - microcolonel 9y ago
    > while you try to figure out the arcane git command for something that I was done with in Mercurial hours ago I sense a lot of resentment in this statement, but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I could understand being frustrated trying to jump right into it, especially with the interface as of the mid-late oughts, but it's fairly straightforward these days. The defaults make sense, and the built-in tools are consistent and plentiful. I doubt I could compose a correct filter-branch from memory, but I don't even think I could find an example for Mercurial, and I doubt the manpage would be as helpful.
    - bsder 9y ago
      > but to be honest I have no idea what people are talking about when it comes to their gripes against Git. Little goes wrong, and when anything does, fixing it is a reflog or a reset away. I will be happy to call you the next time one of my devs does something that causes git to wedge itself into one of those states. It happens about every 2 weeks--and I suspect that it happens more frequently than that. Normally I can unwedge git after reading approximately 10 git pages all claiming to fix my problem (they don't but they probably point me at the brain-damaged command I need). Most of the time ... about once every 3 months everything fails and we have to pull a backup. Fortunately, the devs have now been brainwashed to rsync the repository on at least a daily basis and always before they do anything besides a basic checkout or commit. But, hey, they're using git, and it's what everybody else uses. As someone who uses Mercurial and does some pretty hairy stuff with it, I have never put the system into a wedged state. NEVER. The only time I saw a Mercurial repo get wedged was when the underlying filesystem barfed on itself. Yeah, I'm a touch sore about this because I regularly get to fix problems that WOULD NOT EXIST if the team was in Mercurial instead of git. However, as a manager who likes to think of himself as "good", I cannot force tools on a team unless they actually do measurable damage. I also get sore with the "Well, if you only understood the git model..." I DO understand the git model--much to my horror. The problem is that while a newbie can learn the Mercurial model in about 60 seconds and be productive the git model takes about 60 months to learn and they will still regularly footgun themselves.
- arunc 9y ago
  git won because of GitHub and StackOverflow.