Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

  (email not shown publicly)

Journal of Alias (5735)

Wednesday August 12, 2009
12:15 AM

Does git live up to the hype if we actually measure it?

[ #39450 ]

Clearly, with an inflammatory subject like that you're probably expecting a false question, and I quickly in my journal post say "Yes!" or "No!".

I am, clearly, not pro-git. But I'm actually asking a real question :)

Git still has problems being Windows friendly (most solutions still make you act in a very unix-like manner) and so it's still not on my radar to move any time soon.

But I keep seeing one particular pro-git (and pro-distributed in general) argument come up over and over again in git discussions, the argument that git helps encourage contribution.

And THIS question is one I'm very interested in, it's something that might actually push me towards switching.

I much preferred CVS for it's better branch logic, but because svn makes it so much easier to contribute switching to SVN resulted in improved contribution rates despite the shitty branching.

Has anyone actually measured rate of change and rate of contribution across a SVN to Git conversion?

For my repository, I have quite a good understanding of how many people are contributing.

Here's a better one showing contributors over time, compared to the (epic) contributor growth rate of Padre. CPAN+Modules&project_1=Padre

Is it possible to establish via actual metrics that the diversity of contributors and rate of change flowing into the final production CPAN releases is increased relative to the rate and diversity of change prior to the move?

Have you done it? Can I see the comparative results?

Does the theoretical improvement to contribution result in a real world improvement in contribution? Or does it suffer from the "You are not Linux" scaling problem, that our projects mostly just aren't big enough to benefit?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I used to version all of my modules with darcs. Other than patches from my friends who were already sold on darcs, I received only diffs against CPAN HEAD. Once I moved to git (and perhaps more importantly, github), I did begin receiving patches (many for Any::Moose, a few for App::Nopaste, etc). darcs was cited as a major barrier to entry because it required ghc (which has a notoriously long compilation time).

    So in my experience, choice of VCS definitely impacts user contributions. Whether it matters signi

    • Another quick point I forgot to make: I have had comaint on Log::Dispatch for a month now, but I haven't touched the repository. I don't have any inclination to deal with a fifth version control system (Mercurial) for a single module. I'm sure I'm not alone in this laziness. :)
  • Git's primary advantage, as I see it, is that forks become first-class citizens. Forking is cheap in all good DVCSs, but Git seems particularly strong about not enforcing one central repository with strict commit access.

    I can use git-svn to get some of the benefits of a local Git repo against a centralized SVN repo, but that's a workaround. It's much easier to pull from someone else's Git repo than to apply a series of patches against SVN.

    • I completely agree. For untrusted and non-maintainer forking, it's a world of improvement.

      What I'm curious about is whether this actually results in more changes at the bottom line, or is the flexibility of all this forking largely just something that's nice to have (but won't impact much on the overall progress).

  • Git still has problems being Windows friendly

    Not necessarily a problem for everyone :-) You can't totally blame the original designer if he exploits characteristics of a certain OS to gain speed. After all, being cross-platform is not the top design goal for git.

    • Raising a barrier to contribution is always a problem. It means less people in the world you don't know about yet are able to effectively contribute.

      I've yet to contribute to any git project, because the time investment to learn all the concepts and find a toolchain that doesn't suck just isn't worth it for the sort of small improvements I might want to add.

      And as for cross-platform, it was just fine right up until the point people start promoting it for more than just the kernel.

    • The problem is that the vast majority of programmers use Windows. Sad to say, given that skill doesn't necessarily choose platform, this also means that most of the really good programmers use Windows - and you're shutting them out.

      It is not necessarily a problem that is too difficult to overcome, once one determines one wants to fix it. If all else fails, it should be possible to write a svn-git module, to be able to commit to a git repo as easily as to a svn repo (while, of course, losing the git easy f

  • Despite intents, I end contributing to other projects only very very rarely, for whatever reason. Github in particular, however, has had me make impulse contributions of various small patches on several occasions (two of which ended up ballooning into not so small patches when all was said and done).

    With appropriate cautions and qualifiers applied, that would suggest that the effect being talked about is, at the very least, plausible.

    • It's certainly plausible, but while it was easy for you to make the patches, there's the question of whether those changes make it back to the production release.

      And then there's the question of whether the increase in contributions from people like you is balanced by the decrease in contributions from people that aren't you :)

      • The patches did get pulled in upstream – else I wouldn’t mention this at all.

        But yeah, the latter is a good point.

  • Github has made it really easy for people to send me patches, even for the most trivial things. They fork, make their change, then send me a pull request. Github manages that so I can look at a queue of all my pull requests and apply them in any order I like, and ignore the ones I don't want.

    This has more to say about Github than git though. Github is what I always wanted Sourceforge to be and they could never deliver. And, it's a lot better looking :)

    • So has the number of external contributions applied by you and subsequently released to the CPAN on a month-by-month basis gone up or down?

      • It's definitely gone up, from almost nothing over all time to about 50 in the past month. Not all of that was for stuff showing up on CPAN. Once people realize how easy it is to create a patch, send it, and for my not to lose track of it, they send more.

        I forgot to mention that Github also lets you edit files in the web browser and commit from there, so minor things like doc patches aren't a pain in the ass. You fix the error in the browser, commit, and send a pull request all with a couple of clicks in Git

  • Before GitHub I mostly lurked. I would grab code out of cvs, svn, etc., compile it, fix anything that went wrong for me, and rarely send a patch back. Doing a proper diff, tracking down the right email address to send it to, writing the email, etc. was too much work and I always assumed that if I had the problem then someone else would also have the problem and would jump through the hoops. Now that I have GitHub I fork projects I am compiling and if I have to make a change it is as easy as git add file,

  • I don't think git is going to magically draw more contributors to a project, but it certainly does make the lives of everyone involved with the project easier.

    Even if you end up with the same number of contributions when compared to svn, I still think git is worth the switch. Being able to add a remote repository and cherry-pick a specific patch, or merge a branch in a matter of minutes is great. I don't maintain any popular projects, but for the few that I do get contributions [], it has made my job much quic

    • I don't think git is going to magically draw more contributors to a project, but it certainly does make the lives of everyone involved with the project easier.

      That's my view so far, qualitative and as best I can quantitative*, based this project that converted to git [].

      So I think that Adam's hypothesis that a conversion to git doesn't materially change the contributor profile seems to remain unchallenged.

      * I'm not a statistician, and the data that I extract seems to have a lot of variation, so I'm not comfor

      • To clarify, my main annoyance with git is just general usability stuff on the platform I work on.

        I don't have a hypothesis on contribution rates yet, I'm just looking for data and open to either rates going up or down.

      • Despite a lot of noise about “perforce being the barrier that prevents me contributing”.

        We have learned from the discipline of program optimisation that removing the major bottleneck just reveals the next, and what these people are actually saying is “Perforce was the first thing I ran into that discouraged me beyond my motivation threshold”. Progress exists, though, regardless of whether silver bullets do.

  • I used both CVS and Git, and with possible exception of ad-hoc version control of loosely coupled files, Git is much, much easier to use. Branching and especially merging branches in CVS is deep, dark magic; in Git it is extremly easy.

    See also my answer to Difference between GIT and CVS [] question on StackOverflow (community Q&A site).

    Some of those transfer to comparison between Subversion and Git: see For home projects, can Git (or other DVCS) provide advantage over Subversion? [] also on StackOverf

    • Git is, unfortunately, a lot harder for me.

      But that's not the issue, it's whether or not it makes better for other people, and if that subsequently means they commit more code without me needing to be involved.

  • Putting aside the other technical superiorities, the entry barrier that Git removes is that of one off contributions.

    Once you have an account it's easy to regularly contribute using SVN.

    Git makes it easy to contribute to a project even if you've never contributed before, without knowing what the framework for contribution is, and without needing to be authorized.

    It fills in the gap between emailing patches to someone (which is has technical annoyances but no administrative overhead) and giving commit access

    • (and yes, i've received many many more contributions since I've switched, even if most of them did not become collaborators afterwords)

  • the most important advantages of git over other systems I've used (CVS, svn, svk) are
    • it's fast: I can download the complete history of perl in a few minutes and checkout any commit in seconds;
    • it doesn't (ever, in my experience) lose its mind, which all of the others have done for me on several occasions.

    I (now) like and use some of the other features, like cheap branches, easy rebasing and convenient publishing on github, but if I were looking for a reason to persuade someone to switch those would be my

    • The thing is, I don't particularly care about those things.

      svn is slightly annoyingly slow, but not so much it's a problem.
      svn has never gone bad for me since I moved to FSFS.

      In exchange I get a number of other useful things I'd need to give up if I moved away.

      But all of that is not what this post is about. The bit I'm really curious about is the real world volumes of external contributions.