11 ms·

>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days I confess that my perception o

>git won the mindshare war. I regret this - I would have preferred Mercurial, but it too is not looking real healthy these days I confess that my perception of Mercurial is the diametric opposite of the author's. Recently I believe I have seen a modest resurgence of interest in Hg and increased uptake. Am I just seeing this through some peculiar VCS-warped glasses? I believe that much of the popularity of git stems from github making it very easy to adopt, something that bitbucket doesn't seem to have pulled off as well.

xradionut 13y ago
I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?
- falcolas 13y ago
  As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.
  - wirrbel 13y ago
    The success of git is - apart from the speed - related with its property of being the "stupid content tracker". Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly become quite complicated and in the end it is hard for the user to get a deeper understanding of the system. The funny aspect of this is, that a lot of people complain about Gits bad user interface. It turns out however that Git is really easy to grasp.
    - dasil003 13y ago
      Exactly. The git data model is intuitive and easy to grasp after a short amount of time. The porcelain is poorly designed, but part of that is due to the flexibility of primitives underneath, and the desire to support arbitrary workflows. Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn makes it impossible for it ever achieve 20% of git's functionality simply because things are so poorly defined. After using git for 6 months I understood it better than I did about svn in the previous 5 years. I would prefer a better porcelain, but given that software development is my full time job and that I can use git for all software development regardless of the language, I'm happy to commit a bit of muscle memory to git's idiosyncrasies.
      - chx 13y ago
        > the desire to support arbitrary workflows. Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch. git , I believe , is the textbook case of what the opposite of a user friendly UI is. commands have switches which change the command so fundamentally it should be another command. Which noone wants 'cos there are like 140 commands already. switches which across commands do the same thing but are named differently. The same command doing wildly disparate things without any indication of what's happening -- try git checkout file, and guess what the state of file will be. It might from the staging area or it might come HEAD if it wasn't staged. Nuts.
        Crito 13y ago
        > "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.
        13y ago
  - r0muald 13y ago
    1. Linux 2. GitHub That's it really.
- lmm 13y ago
  Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in the foot with pricing on their new generation (which generation was a pretty radical shift). There's not much chance of git doing that. Java did win the war; its competitors from the time are largely dying (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). You could argue that Ruby has overtaken it, but again the changes over the last ten years of ruby - and the influence of rails - have been enormous. I don't think we should stop trying to make a better VCS. But I do think we should accept that Git has won against bzr and hg in their current form; neither of those will displace git without radical changes that they are probably unsuited to make. Most likely the successor to git will be a new program entirely.
  - belluchan 13y ago
    > Vim did win the war; there's still nothing better I'll just put this here for you: https://code.google.com/p/vim/source/browse/src/eval.c https://code.google.com/p/vim/source/browse/src/eval.c Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means. I've switched to emacs with evil, which in my opinion is better than vim in a lot of ways. > (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here. This isn't an argument, it's a prediction, and a stupid one. Nobody will come back to check your comment in 5 or 10 years and call you out on it. This is just the certain kind of asshat thing you can say and not worry about it coming true or not because you're some anonymous commenter making the internet richer with your irresponsible use of a keyboard.
    - 13y ago
EnderMB 13y ago
I've noticed this, oddly, while my workplace is transitioning to git from Mercurial. A lot of developers using .NET tend to go for Mercurial because a while back it felt a lot nicer to use on Windows. It's why I always preferred using Mercurial. A few .NET shops that use TFP/VSO are moving towards Git for the Visual Studio support, but I've noticed a few Python and PHP developers making the switch to Mercurial. To be honest, I rarely need to do anything more than the basics so neither has a huge benefit for me. Neither feels particularly faster than the other, and both have comparable GUI tools. Aside from when I am pushing stuff to GitHub I tend to use whichever one pops to my head first on a project. I reckon a lot of developers are probably the same.
- dustinupdyke 13y ago
  It seems that most .NET devs prefer something baked straight into Visual Studio and my experience has been that this is part of the problem in getting those teams to migrate to Git, which is most powerful from the command line. Personally, I greatly prefer my source control system to be separate from my development environment or IDE.
  - rat87 13y ago
    Microsoft released a git plugin for VS.
  - bunderbunder 13y ago
    Git's pretty well baked straight into Visual Studio now that it's built into the latest version of Team Foundation Server. Mercurial's the one where you really want to be using it from the command line. It's had VS plugins, but they're all kind of janky by comparison.
    - dgesang 13y ago
      Or use TortoiseHg or SourceTree, if you're not comfortable with the CLI. They both work great. Also, if you need to host 'your own github', try RhodeCode.
- 13y ago
thrillgore 13y ago
I used Mercurial with a hg-git plugin back in the day as we were a Mac-only shop and I was the only schlub with a Windows machine (I was in charge of fixing IE issues). Mercurial was very good back then, when Git performance was subpar on Windows. Git on Windows is now blazing fast enough that msysgit will get you by. I still favor the Git workflow even when I am using other SCMs (like right now, where we have a Subversion dependency)
sdague 13y ago
Yes, there are plenty of local maxima, but this is a pretty nice look at the global picture - http://redmonk.com/sogrady/2013/12/19/dvcs-and-git-2013/ http://redmonk.com/sogrady/2013/12/19/dvcs-and-git-2013/ - and git definitely won the mindshare war by those numbers.
binarycrusader 13y ago
Yep, I don't understand the author's assertions about Mercurial either. Mercurial remains a better choice for a few use cases where git simply falls flat. Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. And realistically, perforce or other solutions appear to be even more popular among that particular developer segment. Personally, I use Mercurial wherever possible, but that's not because I believe Mercurial to be technically superior, it's just because I hate git's UI. Perhaps among the general FOSS community git is more popular, but both git and Mercurial have yet to met the needs of many developers.
- bitwize 13y ago
  Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.
  - binarycrusader 13y ago
    Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4. Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4. Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a large following among the corporate world. And many of the largest tech companies I'm aware of don't use p4 primarily; they use git, mercurial, svn, cvs, SourceSafe, home-grown solutions, etc.
    - voltagex_ 13y ago
      Are that many people really using SourceSafe still? TFS is now Microsoft's preferred solution, although I don't know what they use internally.
rbehrends 13y ago
As far as I can tell, Mercurial is being actively developed (i.e., updates being pushed out on a roughly monthly basis), and it's also actively being used. It isn't used as much in the open source community (probably the GitHub effect), but that doesn't mean it's "not looking real healthy" (anymore than OS X does compared to Windows). Bazaar is a different story. Technically speaking, Bazaar isn't going away anytime soon. Canonical's development depends too much on it. The primary problem with Bazaar is that updates on Canonical's side are pretty much limited to dealing with issues that Canonical has, and there is little activity with respect to getting other bugs/issues fixed/addressed. This is unfortunate, because Bazaar does do a few things better than either Git or Mercurial.
- alwillis 13y ago
  Yes, Mercurial is being actively developed; Facebook has a great post about why Mercurial and not Git with data: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...
mark_l_watson 13y ago
Bitbucket is nice. I use bitbucket for all of my private git repos, while using github for all of my public repos (and three or four private repos). Bitbucket provides a good service.
alwillis 13y ago
Yes, Mercurial is looking quite healthy—Facebook details why Git doesn't work for them and all of the improvements they've made to Mercurial for their repo which is several times the size of the Linux kernel: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

xradionut 13y ago

I hate when people say "git won the war", it sounds like an excuse to close minds and stop progress. What if "Microsoft won the war"? Or vim? Or IBM? Or Java? Or Taco Bell?

falcolas 13y ago
As an avid git user, I believe that git's victory against current tools does nothing to stop someone from creating a better DVCS in the future. They'll just have to identify why git won and address those points, if they want to dethrone git.
- wirrbel 13y ago
  The success of git is - apart from the speed - related with its property of being the "stupid content tracker". Git's architecture is a simple bottom-up engineering approach. The user interface (porcellain) builts upon a conceptually simple core (plumbing). Other VCS have defined nice UI which where then implemented by a core that depends on the UI. This top-down approach means that the core components can suddenly become quite complicated and in the end it is hard for the user to get a deeper understanding of the system. The funny aspect of this is, that a lot of people complain about Gits bad user interface. It turns out however that Git is really easy to grasp.
  - dasil003 13y ago
    Exactly. The git data model is intuitive and easy to grasp after a short amount of time. The porcelain is poorly designed, but part of that is due to the flexibility of primitives underneath, and the desire to support arbitrary workflows. Contrast with svn which attempts a very clean porcelain interface with a completely muddled data model underneath. The conflation of repositories, directories and branches in svn makes it impossible for it ever achieve 20% of git's functionality simply because things are so poorly defined. After using git for 6 months I understood it better than I did about svn in the previous 5 years. I would prefer a better porcelain, but given that software development is my full time job and that I can use git for all software development regardless of the language, I'm happy to commit a bit of muscle memory to git's idiosyncrasies.
    - chx 13y ago
      > the desire to support arbitrary workflows. Now I am laughing and laughing bitterly. git supports one workflow -- the massively decentralized one. To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from, the one that bzr calls a bound branch. git , I believe , is the textbook case of what the opposite of a user friendly UI is. commands have switches which change the command so fundamentally it should be another command. Which noone wants 'cos there are like 140 commands already. switches which across commands do the same thing but are named differently. The same command doing wildly disparate things without any indication of what's happening -- try git checkout file, and guess what the state of file will be. It might from the staging area or it might come HEAD if it wasn't staged. Nuts.
      - Crito 13y ago
        > "To this day you can't have a simple workflow with git, the one that cvs/svn supported and practically all small project would benefit from" What? Of course you can. I've worked on teams that did it. You are talking total rubbish.
        13y ago
- r0muald 13y ago
  1. Linux 2. GitHub That's it really.
lmm 13y ago
Microsoft did win the war; very little progress has been made by its competitors from the time; what's had success has been new OSes - OSX, iOS and Android (which while built of GNU/Linux pieces, is radically different from traditional GNU/Linux - enough to qualify as a different OS IMO, since the API is different). Vim did win the war; there's still nothing better. IBM did win the war, and then shot themselves in the foot with pricing on their new generation (which generation was a pretty radical shift). There's not much chance of git doing that. Java did win the war; its competitors from the time are largely dying (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). You could argue that Ruby has overtaken it, but again the changes over the last ten years of ruby - and the influence of rails - have been enormous. I don't think we should stop trying to make a better VCS. But I do think we should accept that Git has won against bzr and hg in their current form; neither of those will displace git without radical changes that they are probably unsuited to make. Most likely the successor to git will be a new program entirely.
- belluchan 13y ago
  > Vim did win the war; there's still nothing better I'll just put this here for you: https://code.google.com/p/vim/source/browse/src/eval.c https://code.google.com/p/vim/source/browse/src/eval.c Yes that's nearly 25,000 lines of mixed spaces and tab filled pre-C89 C with 492 occurrences of #idef, many appearing in the middle of a function definition. I recently ran vim with debug symbols compiled and it was nice enough to dump a nice 4GB regular expression log file in my project directory. The way to turn that off is to find some ifdefs and comment them out. If vim won then well, I'm not sure what winning means. I've switched to emacs with evil, which in my opinion is better than vim in a lot of ways. > (Objective-C has had a kind of zombie revival due to iOS, but I don't expect it to last). Yeah ok, "zombie-revival" sure, your credibility gets a score of 0 here. This isn't an argument, it's a prediction, and a stupid one. Nobody will come back to check your comment in 5 or 10 years and call you out on it. This is just the certain kind of asshat thing you can say and not worry about it coming true or not because you're some anonymous commenter making the internet richer with your irresponsible use of a keyboard.
  - 13y ago

EnderMB 13y ago

I've noticed this, oddly, while my workplace is transitioning to git from Mercurial. A lot of developers using .NET tend to go for Mercurial because a while back it felt a lot nicer to use on Windows. It's why I always preferred using Mercurial. A few .NET shops that use TFP/VSO are moving towards Git for the Visual Studio support, but I've noticed a few Python and PHP developers making the switch to Mercurial. To be honest, I rarely need to do anything more than the basics so neither has a huge benefit for me. Neither feels particularly faster than the other, and both have comparable GUI tools. Aside from when I am pushing stuff to GitHub I tend to use whichever one pops to my head first on a project. I reckon a lot of developers are probably the same.

dustinupdyke 13y ago
It seems that most .NET devs prefer something baked straight into Visual Studio and my experience has been that this is part of the problem in getting those teams to migrate to Git, which is most powerful from the command line. Personally, I greatly prefer my source control system to be separate from my development environment or IDE.
- rat87 13y ago
  Microsoft released a git plugin for VS.
- bunderbunder 13y ago
  Git's pretty well baked straight into Visual Studio now that it's built into the latest version of Team Foundation Server. Mercurial's the one where you really want to be using it from the command line. It's had VS plugins, but they're all kind of janky by comparison.
  - dgesang 13y ago
    Or use TortoiseHg or SourceTree, if you're not comfortable with the CLI. They both work great. Also, if you need to host 'your own github', try RhodeCode.
13y ago

thrillgore 13y ago

I used Mercurial with a hg-git plugin back in the day as we were a Mac-only shop and I was the only schlub with a Windows machine (I was in charge of fixing IE issues). Mercurial was very good back then, when Git performance was subpar on Windows. Git on Windows is now blazing fast enough that msysgit will get you by. I still favor the Git workflow even when I am using other SCMs (like right now, where we have a Subversion dependency)

sdague 13y ago

Yes, there are plenty of local maxima, but this is a pretty nice look at the global picture - http://redmonk.com/sogrady/2013/12/19/dvcs-and-git-2013/ http://redmonk.com/sogrady/2013/12/19/dvcs-and-git-2013/ - and git definitely won the mindshare war by those numbers.

binarycrusader 13y ago

Yep, I don't understand the author's assertions about Mercurial either. Mercurial remains a better choice for a few use cases where git simply falls flat. Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. And realistically, perforce or other solutions appear to be even more popular among that particular developer segment. Personally, I use Mercurial wherever possible, but that's not because I believe Mercurial to be technically superior, it's just because I hate git's UI. Perhaps among the general FOSS community git is more popular, but both git and Mercurial have yet to met the needs of many developers.

bitwize 13y ago
Among game developers, in particular, because of their need to have revision control for large assets, Mercurial seems to be more popular than git due to the large files extension. Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4.
- binarycrusader 13y ago
  Most game devs -- I'd say even most devs in grown-up, professional shops -- use p4. Hence why I said "realistically, perforce or other solutions appear to be even more popular among that particular developer segment." My comment you quoted was comparing the popularity of Mercurial to Git, not p4. Also, I'd disagree with your assertion regarding "most devs in grown-up, professional shops". Microsoft's SourceSafe has a large following among the corporate world. And many of the largest tech companies I'm aware of don't use p4 primarily; they use git, mercurial, svn, cvs, SourceSafe, home-grown solutions, etc.
  - voltagex_ 13y ago
    Are that many people really using SourceSafe still? TFS is now Microsoft's preferred solution, although I don't know what they use internally.

rbehrends 13y ago

As far as I can tell, Mercurial is being actively developed (i.e., updates being pushed out on a roughly monthly basis), and it's also actively being used. It isn't used as much in the open source community (probably the GitHub effect), but that doesn't mean it's "not looking real healthy" (anymore than OS X does compared to Windows). Bazaar is a different story. Technically speaking, Bazaar isn't going away anytime soon. Canonical's development depends too much on it. The primary problem with Bazaar is that updates on Canonical's side are pretty much limited to dealing with issues that Canonical has, and there is little activity with respect to getting other bugs/issues fixed/addressed. This is unfortunate, because Bazaar does do a few things better than either Git or Mercurial.

alwillis 13y ago
Yes, Mercurial is being actively developed; Facebook has a great post about why Mercurial and not Git with data: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...

mark_l_watson 13y ago

Bitbucket is nice. I use bitbucket for all of my private git repos, while using github for all of my public repos (and three or four private repos). Bitbucket provides a good service.

alwillis 13y ago

Yes, Mercurial is looking quite healthy—Facebook details why Git doesn't work for them and all of the improvements they've made to Mercurial for their repo which is several times the size of the Linux kernel: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ https://code.facebook.com/posts/218678814984400/scaling-merc...