10 ms·

Git appears to be fast becoming the standard DVCS. Is there any reason that all reasonably well-run projects should not be using git? GitHub seems vastly supe

Git appears to be fast becoming the standard DVCS. Is there any reason that all reasonably well-run projects should not be using git? GitHub seems vastly superior to BitBucket, and git itself seems pretty much isomorphic to hg (albeit with worse syntax). (This ignores darcs, bzr, etc., but those never seemed terribly competitive for mindshare.) Furthermore, the network effects (with pull requests on Github, not having to have people learn a new DVCS to commit to your project, etc.) seem huge. Aside from some new innovation on the scale of switching from a centralized VCS to a distributed VCS, I can't imagine anything that would cause me to try to start a project in something other than git, learn another VCS other than git, or try to convert someone to another VCS other than git. Is this the wrong attitude? Is there any chance that Python might see the light and switch to git from hg? At this stage, choosing hg over git for reasons that seem increasingly irrelevant (better Windows support at the time, written in C/shell rather than Python) is starting to look like a worse and worse historical decision.

sho_hn 15y ago
I'm a Git guy myself, but FWIW: While Python seems to be the Mercurial project everyone remembers because it was the most recent biggie to adopt it, there's also Mozilla, and the Ex-Sun-now-Oracle projects and a couple of others.
- socratic 15y ago
  Ah, very interesting list. I guess I think of Python differently from the other projects in your list because the choice of DVCS chosen by the core team seems to me to impact the DVCS that someone will choose for their library in the language. I don't really have any evidence for that, however. Do you think that (a) language communities tend to standardize on the same version control, and if so, (b) that language communities tend to standardize on the version control of the core project for the language?
  - sho_hn 15y ago
    I think (a) is true, yes. I've written about the migration of KDE from SVN to Git in a longer comment elsewhere in this thread, and Qt (not a language, but the library framework most of KDE's products build upon) switching to Git was definitely a significant factor in Git gaining traction among members of the KDE community. The KDE community consciously wanted to harness the potential synergy it saw in the KDE and Qt ecospheres syncing up on the same VCS. OTOH, I think the Python community is pragmatic enough that it wouldn't have chosen Mercurial over Git if it being written in Python would have been the only point in Mercurial's favor, from the POV of their requirement set. But it probably does have an emotional/affinity effect, after all language developers do obviously have to care about language! :) Interestingly, one of the best Git libraries around is actually a pure Python implementation of Git and its protocols: Dulwich.
Ixiaus 15y ago
I'm a pious hg user - even gave git a good run (mostly because of Github). I can't get over how amazing mercurial patch-queues are. Big win. I love mercurial's easy plugin development and hooks (thank you Python); I love how many awesome plugins exist for mercurial. On and on and on.
- jlogsdon 15y ago
  I keep seeing people talk about all the good of hg over git, but I haven't seen anything that really sets it apart. If you were doing a sales pitch, what would you show that hg has over git? What are some specific plugins that ease your development or release process? What are some real-world advantages of the hg patch-queue over how git handles pulls? I'm honestly curious. I just haven't seen anything to sell me on why hg is so much better than git (or even the other way around).
  - owenmarshall 15y ago
    From the perspective of a longtime hg user who switched jobs and is now in git land: hg is easier to pick up and start using than git. git lets you do incredible things with your tree, things that hg forbids or makes impossible. But git also lets you make big mistakes, and isn't very nice about helping you fix them. hg, on the other hand, has a much nicer learning curve. As an example, try to forget everything you know about version control and type `hg help push` and `git help push`. Which one would you be able to parse? Personally, when I read "The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>", I want to punch a baby. At the end of the day, if I want to transition a team away from SVN onto a DVCS, I'd pick hg -- just because it lets a team Get Shit Done without spending a ton of time learning a new VCS. But if I'm starting my own project? I'd pick git in a heartbeat.
  - jhonnycano 15y ago
    Besides the simplicity when starting to use a DVCS, i would add the simplicity for setting up a server (At least on Windows). There are a lot of organizations which need a centralized repo. And setting up mercurial for serving is a breeze. That's my 2 cents.
digitallogic 15y ago
As someone who choose hg over git w/o reviewing bitbucket vs github, I'm curious what makes github superior. Can you elaborate?
- socratic 15y ago
  It is difficult to answer your question without knowing your purposes and goals. What aspects do you think would make a quality version control host? For me, the primary issue is size. A large number of people use Github. This means that social features like networks of forks of repositories and pull requests are substantially more compelling. This also means that many related websites (bug trackers, project managers) have Github integration. Further, it makes much more sense to design custom desktop apps for Github because it is what everyone uses. Lastly, the more people are familiar with Github, the easier it becomes to suggest it for a project or to contribute to a random Github-based project. The APIs, UI, and general flow of Github are competently designed, but I do not think these are necessarily the core of its success. (I do believe these parts of Github, however, to be better than the competition.) Ultimately, Github is in a unique position because of its (and git's) popularity. Social features that would not work on other sites work on Github. I am sure that the developers and designers of, e.g., BitBucket and Google Code are smart people, but without users they feel a little like ghost towns. This is odd, because I had thought of VCS hosting as very much a commodity before Github.
georgieporgie 15y ago
Git appears to be fast becoming the standard DVCS. Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios: http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&l= http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&#... Git has been picking up speed, but Subversion seems to be (nearly) matching its growth. This makes me feel slightly less bad that all my personal projects are checked into Subversion on Dreamhost. :-)
- fragsworth 15y ago
  To add further evidence toward your argument, consider also the alternative name, "svn": http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2C+git&l= http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2... The popularity would actually be the sum of both.
  - whacker 15y ago
    Not necessarily. Some entries might refer to both but be in the same entry. So the correct way to calculate totals would be `subversion + svn - (subersion and svn)`
    - fragsworth 15y ago
      You're right, but in my experience any mention of subversion in a job description tends to only happen once in the document.
    - stephenhalter 15y ago
      The following link should provide the correct unions of job postings: http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+bzr+or+bazaar%2C+darcs%2C+svn+or+subversion%2C+tfs+or+%22team+foundation+server%22&l= http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+...
- socratic 15y ago
  You present an interesting tool for settling such debates. However, I believe the more appropriate URL would be: http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+bzr%2C+darcs http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+... Obviously, cvs and svn will be with us for some time still, but those are not distributed version control systems (DVCS). However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever?

sho_hn 15y ago

I'm a Git guy myself, but FWIW: While Python seems to be the Mercurial project everyone remembers because it was the most recent biggie to adopt it, there's also Mozilla, and the Ex-Sun-now-Oracle projects and a couple of others.

socratic 15y ago
Ah, very interesting list. I guess I think of Python differently from the other projects in your list because the choice of DVCS chosen by the core team seems to me to impact the DVCS that someone will choose for their library in the language. I don't really have any evidence for that, however. Do you think that (a) language communities tend to standardize on the same version control, and if so, (b) that language communities tend to standardize on the version control of the core project for the language?
- sho_hn 15y ago
  I think (a) is true, yes. I've written about the migration of KDE from SVN to Git in a longer comment elsewhere in this thread, and Qt (not a language, but the library framework most of KDE's products build upon) switching to Git was definitely a significant factor in Git gaining traction among members of the KDE community. The KDE community consciously wanted to harness the potential synergy it saw in the KDE and Qt ecospheres syncing up on the same VCS. OTOH, I think the Python community is pragmatic enough that it wouldn't have chosen Mercurial over Git if it being written in Python would have been the only point in Mercurial's favor, from the POV of their requirement set. But it probably does have an emotional/affinity effect, after all language developers do obviously have to care about language! :) Interestingly, one of the best Git libraries around is actually a pure Python implementation of Git and its protocols: Dulwich.

Ixiaus 15y ago

I'm a pious hg user - even gave git a good run (mostly because of Github). I can't get over how amazing mercurial patch-queues are. Big win. I love mercurial's easy plugin development and hooks (thank you Python); I love how many awesome plugins exist for mercurial. On and on and on.

jlogsdon 15y ago
I keep seeing people talk about all the good of hg over git, but I haven't seen anything that really sets it apart. If you were doing a sales pitch, what would you show that hg has over git? What are some specific plugins that ease your development or release process? What are some real-world advantages of the hg patch-queue over how git handles pulls? I'm honestly curious. I just haven't seen anything to sell me on why hg is so much better than git (or even the other way around).
- owenmarshall 15y ago
  From the perspective of a longtime hg user who switched jobs and is now in git land: hg is easier to pick up and start using than git. git lets you do incredible things with your tree, things that hg forbids or makes impossible. But git also lets you make big mistakes, and isn't very nice about helping you fix them. hg, on the other hand, has a much nicer learning curve. As an example, try to forget everything you know about version control and type `hg help push` and `git help push`. Which one would you be able to parse? Personally, when I read "The format of a <refspec> parameter is an optional plus +, followed by the source ref <src>, followed by a colon :, followed by the destination ref <dst>", I want to punch a baby. At the end of the day, if I want to transition a team away from SVN onto a DVCS, I'd pick hg -- just because it lets a team Get Shit Done without spending a ton of time learning a new VCS. But if I'm starting my own project? I'd pick git in a heartbeat.
- jhonnycano 15y ago
  Besides the simplicity when starting to use a DVCS, i would add the simplicity for setting up a server (At least on Windows). There are a lot of organizations which need a centralized repo. And setting up mercurial for serving is a breeze. That's my 2 cents.

digitallogic 15y ago

As someone who choose hg over git w/o reviewing bitbucket vs github, I'm curious what makes github superior. Can you elaborate?

socratic 15y ago
It is difficult to answer your question without knowing your purposes and goals. What aspects do you think would make a quality version control host? For me, the primary issue is size. A large number of people use Github. This means that social features like networks of forks of repositories and pull requests are substantially more compelling. This also means that many related websites (bug trackers, project managers) have Github integration. Further, it makes much more sense to design custom desktop apps for Github because it is what everyone uses. Lastly, the more people are familiar with Github, the easier it becomes to suggest it for a project or to contribute to a random Github-based project. The APIs, UI, and general flow of Github are competently designed, but I do not think these are necessarily the core of its success. (I do believe these parts of Github, however, to be better than the competition.) Ultimately, Github is in a unique position because of its (and git's) popularity. Social features that would not work on other sites work on Github. I am sure that the developers and designers of, e.g., BitBucket and Google Code are smart people, but without users they feel a little like ghost towns. This is odd, because I had thought of VCS hosting as very much a commodity before Github.

georgieporgie 15y ago

Git appears to be fast becoming the standard DVCS. Whenever I read a statement about popularity of technology, the first thing I do is check the job ratios: http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&l= http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+git&#... Git has been picking up speed, but Subversion seems to be (nearly) matching its growth. This makes me feel slightly less bad that all my personal projects are checked into Subversion on Dreamhost. :-)

fragsworth 15y ago
To add further evidence toward your argument, consider also the alternative name, "svn": http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2C+git&l= http://www.indeed.com/jobtrends?q=cvs%2C+subversion%2C+svn%2... The popularity would actually be the sum of both.
- whacker 15y ago
  Not necessarily. Some entries might refer to both but be in the same entry. So the correct way to calculate totals would be `subversion + svn - (subersion and svn)`
  - fragsworth 15y ago
    You're right, but in my experience any mention of subversion in a job description tends to only happen once in the document.
  - stephenhalter 15y ago
    The following link should provide the correct unions of job postings: http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+bzr+or+bazaar%2C+darcs%2C+svn+or+subversion%2C+tfs+or+%22team+foundation+server%22&l= http://www.indeed.com/jobtrends?q=git%2C+hg+or+mercurial%2C+...
socratic 15y ago
You present an interesting tool for settling such debates. However, I believe the more appropriate URL would be: http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+bzr%2C+darcs http://www.indeed.com/jobtrends?q=git%2C+hg%2C+mercurial%2C+... Obviously, cvs and svn will be with us for some time still, but those are not distributed version control systems (DVCS). However, you raise a good question: is distributed version control so much better than centralized version control that we will all eventually be using a DVCS? Or are cvs and svn so much easier to understand for new and/or low quality developers that cvs, svn, and others will be with us forever?