Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Open Source Programming

10,000 Commits To an Open-source Project 101

Posted by timothy from the yeah-but-can-do-you-dance? dept.
tgeller writes "British web designer Jonathan Brown tweeted that Drupal creator Dries Buytaert has surpassed 10,000 commits to the open-source content-management system he created ten years ago, Drupal. In a private email, Dries said, 'I'm mostly committing other people's patches: Credit really goes to the community at large.' Still, it's rare for individual to log that many commits. Can anyone claim more?"
This discussion has been archived. No new comments can be posted.

10,000 Commits To an Open-source Project More

10,000 Commits To an Open-source Project

Comments Filter:

  • i'm sure the maintainers of projects like ffmpeg (now libav) and x264 would be getting up there.

    • Re: (Score:2)

      by jisom ( 113338 )

      i'm sure the maintainers of projects like ffmpeg (now libav) and x264 would be getting up there.

      libav is actually a fork of ffmpeg, not a rename. ffmpeg is still active.

      • i know, but to paraphrase my favourite slashdot troll: "ffmpeg = stagnated".

        look at the rate of commits to both projects, and more importantly, look at the number of significant forks and projects that have switched over to libav for their media needs.

        • i know, but to paraphrase my favourite slashdot troll: "ffmpeg = stagnated".

          ur mum's face is a ffmpeg

    • FFMPEG is currently at 26402 - so uber fail on TFA.

  • I am watching a rather basic open source game and the creator makes _everything_ into a atomic commit.
      Most commit change logs are only a few characters.

    Clocked in 2k commits in less than a year and still only basic functionality...

    • Well this is how you should do it. Merging and Bug-tracking will be way easier this way, rather than one commit saying "improved everything today"

      • Re: (Score:2)

        by gl4ss ( 559668 )

        bullshit, if he is just sketching the game engine, which he is probably doing, then committing every single change is just "hey look precisely what i'm doing", it's bullshit and doesn't show where the big changes of thought happen(the real 'patches'). and it builds up an atmosphere where it's harder for the author(psychologically) to wipe everything and rewrite the core parts in one go as a test if that would be a better way. that way he might have something else than just 'basic functionality'.

        with 2k sav

        • Re: (Score:1)

          by Anonymous Coward

          If each commit leaves the source tree in a good way (compiles, doesn't crash, etc) then higher commit granularity is a good thing. If the tree is intentionally left broken for several commits then the added granularity is pointless. (Your commits generally should not depend on future commits rather they should depend on previous commits.)

          People who use git correctly understand this because of git's powerful bisection capability. Users of other SCMs tent to think that commits should be limited to one fil

    • There is a balance point between too many commits and the one big commit. Some of it also depends on your version control system (distributed or centralized).

      Was there a concrete reason for that 1-line code change? Does it address a specific bug? Then it's definitely a worthwhile commit. Drafting out a new module? I generally commit about once an hour, just on the off-chance that the computer decides to freeze up / hang / crash / etc. Usually whenever I finish a major block of code or in the case of

  • How many commits do you suppose Linus Torvalds has made over the years, between the original BitKeeper revision control and the more recent Git?

  • Sure (Score:2, Insightful)

    by Anonymous Coward

    Can anyone claim more?

    I can claim whatever you want.

    • ...but committing to an open source project means anyone can verify the claim.

    • My first thought on reading TFS is that the leader of pretty much any popular project will have that many commits. A quick look at the top LLVM contributors [ohloh.net] shows Chris Lattner as having over 26,000 commits (it counts his 4,000 commits to clang as separate). As with the original poster, a great many of these are by other people (around 30 are mine, from before I got commit access), but quite a lot are probably his, since he's worked on the project full time for a few years.

      That said, Ohloh puts me in t

  • Yes, Jim Meyering on coreutils (Score:5, Informative)

    by James Youngman ( 3732 ) <jay@NoSpam.gnu.org> on Tuesday May 17, 2011 @06:55PM (#36160414) Homepage

    ~/source/GNU/coreutils/coreutils$ git log | grep -c '^Author: Jim Meyering'
    23652
    ~/source/GNU/coreutils/coreutils$ git log | egrep '^(Date:|Author: Jim Meyering)' | tail -n 2
    Author: Jim Meyering
    Date: Sat Oct 31 20:42:48 1992 +0000

    • # of Commits is a horrible metric (Score:5, Insightful)

      by syousef ( 465911 ) on Tuesday May 17, 2011 @08:53PM (#36161376) Journal

      coreutils rocks and I don't recognise Jim Meyering's name so I'm not casting aspersions, but doesn't it also depend on the value of the commit. I have on occassion committed more on a bad day (to fix my mistakes) than on a good day. So does that mean my mistake laden days are more productive? Should my boss look at that metric and give me a raise instead of the developers that get it right the first time?

      No! This seems to be a very very silly metric indeed to me. Worse than kloc by an order of magnitude. Good for nothing but a pissing contest.

      • Yeah, I don't have very many commits either.

      • Yup, it's a silly metric. For one of the open source projects that I contribute to, there's a day in the not-so-distant past when I committed 20 times, and all of them got reverted later (fixing bugs identified by the static analyser without testing properly - not a good idea). On the other hand, you'll find a single commit where I rewrote a small family of commonly used classes, simplified the code considerably, and got a significant speedup. Which day do you think was more productive?

        I'm not even su

      • coreutils rocks and I don't recognise Jim Meyering's name so I'm not casting aspersions, but doesn't it also depend on the value of the commit. I have on occassion committed more on a bad day (to fix my mistakes) than on a good day. So does that mean my mistake laden days are more productive? Should my boss look at that metric and give me a raise instead of the developers that get it right the first time?

        No, that means your commits arent frequent enough. You're probably one of those guys that just can't be bothered to use proper vc techniques and sits and codes for five weeks and then blame everyone else when it is impossible to integrate your code with the rest of the system. There is a strong correlation between how often developers check in their code and how proficient they are. Weak developers consider it to be a chore to have to write legible commit messages to describe what their code does. The reaso

    • Jim Meyering is not a human being at all http://www.ohloh.net/accounts/meyering [ohloh.net]

    • Re: (Score:2)

      by sqldr ( 838964 )
      Well, we got there, although I'm not sure anybody was doing anything constructive at the time..

      $ svn log -r10000:10001 README.txt

      -----
      r10000 | g........ | 2010-03-22 14:59:06 +0000 (Mon, 22 Mar 2010) | 1 line

      10000th COMMIT!!  I WIN!!

      -----
      r10001 | e..... | 2010-03-22 15:26:46 +0000 (Mon, 22 Mar 2010) | 1 line

      BASTARD!!!

  • Get out your rulers! (Score:4, Funny)

    by Anonymous Coward on Tuesday May 17, 2011 @06:57PM (#36160426)

    What, dick-measuring gets the Slashdot front page now?

    • i just spent my 15 points in yet another conservative "don't tax the rich" circlejerk thread.

      but one of my hobbies is modding AC posts "insightful". i guess your timing was off, or mine was.

    • Re: (Score:2)

      by gl4ss ( 559668 )

      if you're an open source project everyone knows about but going downhill in popularity then slashvertisements might be just the ticket to ride for you! apply today!

      (it's more of an measurement of how often you measure your dick, not it's size. easy to generate commits, harder to change the overall quality of the project, that could mean dumping out a lot of commits from mattering at all)

  • 10.000 commits (Score:5, Funny)

    by CharlyFoxtrot ( 1607527 ) on Tuesday May 17, 2011 @07:00PM (#36160462)

    Must all be done by female coders as we all know men can't commit.

  • Ya, i could commit even more, but if they are worthless bits of poor code, does it matter?

    • Considering I briefly evaluated Drupal last week and had to MANUALLY edit the code to get it to create a valid dsn to an af_unix socket because it kept adding the "unix://" protocol bit to the dsn string and wouldn't generate the string unless it already had a "unix://" bit -- talk about fucked up. I lost all confidence in Drupal and stopped my evaluation right there. A quick search on google shows this has been an issue for Drupal users for a few years now. Talk about confidence inspiring.

      If they can't ma

  • In other news... (Score:4, Insightful)

    by NonUniqueNickname ( 1459477 ) on Tuesday May 17, 2011 @07:11PM (#36160562)
    Your employer just adopted "commits-per-day" as a productivity metric. You are expected to put in at least 6. Why? Because you're getting paid to do your job. You had better one-up that British guy who racks up 5 commits-per-day on free software.

    • Re: (Score:1)

      by m50d ( 797211 )
      Do people really commit that rarely? I'd expect to be committing at least once every half-hour when I'm working, and probably more frequently. And doing that means you end up with better code - you work more incrementally, more agilely, because each commit has to stand alone.

  • Webmin commits (Score:3)

    by jcam2 ( 248062 ) on Tuesday May 17, 2011 @07:12PM (#36160568) Homepage

    I'm up to 15644 commits in total on the Webmin / Virtualmin projects..

  • ikiwiki: 10262 (Score:4, Informative)

    by joey ( 315 ) <joey@kitenet.net> on Tuesday May 17, 2011 @07:13PM (#36160576) Homepage

    I started ikiwiki in 2006 and have since committed 10262 times. Some of those were web-based edits committed to its wiki's git repository, most were code changes.

  • Software as a form of publication. (Score:4, Interesting)

    by __aapopf3474 ( 737647 ) on Tuesday May 17, 2011 @07:20PM (#36160622)
    I have 30874 on the Ptolemy II [ptolemy.org] repository, see http://www.ohloh.net/accounts/cxbrx [ohloh.net]. Hauke Fuhrmann put up Codeswarm [ucdavis.edu] videos of the software evolution of the Ptolemy II project. See Chaotic [vimeo.com], Less Chaotic [vimeo.com]. The number of commits is a poor measure though. I tend to make lots of small commits while cleaning code. A student doing a Ph.D., may make many fewer commits, but their commits have greater impact in the form of support for their Ph.D. We see software as a form of publication, see Software Practice in the Ptolemy Project [berkeley.edu].

    • Re: (Score:3)

      by tgeller ( 10260 )
      Thanks for posting one of the first *useful* comments. I'm going to use it as my soapbox. :) I'm the story's source, and never meant to suggest suggest number of commits implies code quality or anything of the sort. Dries doesn't feel that way either, as his comment shows. I was just celebrating it, as one celebrates a birthday -- and asking who the "oldest" person is.
  • I suspect that over the last six years Anthm (Anthony Minnesale) has logged over 10,000 commits to the FreeSWITCH project. For more info, check out freeswitch.org or #freeswitch on freenode.

  • I use a GIT repo to sync my personal changes between all my PCs constantly. Literally, I have a cron job doing git commit & git push, and use the auto-save feature of my document editors in order to provide "ChromeOS" like synchronization.

    I have over 80,000 on this current repo -- I'll back it up and start a new one next month.

    • Is it open source?
    • You should rewrite the scripts to only push changes when there are actual changes to be made.

      That will drastically reduce your few thousand or few tens of thousands of commits per year down quite a bit.

      (We had an automated push system for log files that pushed them into a SVN repository once an hour. That logged about 8760 commits per year. But since log files don't actually change every hour a rewrite of the scripts on the new server will cut that down to a small fraction of the old volume.)
    • 80.000 commits and your first backup will be made a month from now? Hmm..

  • http://dev.gentoo.org/~tove/stats/gentoo-x86/cvs-log-sum.txt [gentoo.org]

    I'm number 20 on that list, having recently surpassed 10k commits to Gentoo myself (in 7 years). The top of our list is somebody with 70k commits.

    - robbat2@gentoo

  • Dani Megert [ohloh.net] : 14,143 commits on Eclipse Platform + JDT

    Darin Wright : 12,642 commits on Eclipse Platform [ohloh.net] + JDT [ohloh.net]

  • quality not quantity (Score:1)

    by Anonymous Coward

    Counting commits is about as valuable as counting lines of code.

    • Re: (Score:2)

      by joey ( 315 )

      While basically true, an interesting ration is LOC/commits. In one of my projects, the ratio is 5.35. Another, 5.01.

  • I'm not exactly sure of his total commit count, but I feel pretty confident that Milo [thedailywtf.com] is a strong contender for highest number of commits.

  • I do a lot of small and large commits for MidnightBSD. ports work or web based projects often generate a lot of commits. I tend to do small, logic commits.

    https://www.ohloh.net/accounts/laffer1 [ohloh.net]

    11737 just on MidnightBSD since ~2006.

    That doesn't imply that I've done more work, or that my contributions are better than anyone else's.

  • Huge number of commits. The actual value of those commits is negative since you made it much harder for others to see the real changes when they diff between versions.

    In fact, the sequence of events will likelly be:
    - Re-indent all the code "your way"
    - Commit all
    - Huge flame-war follows. The discussion boards and mailing lists go into meltdown. Your real e-mail is added to a number of goatse mailing lists. People are about to kick you out of the project.
    - You undo all your changes, thus making another huge n

  • when they were being measured, i believe the statistics were somewhere around 300+ per month. at over 3 years of development at the time, that would easily exceed 10,000 commits. if i had continued on the project, at that rate, the number of commits would be somewhere exceeding 70,000. rapid and proper incremental code development is like that.

    l.

  • At work I'll usually do one commit per day in the evening. I start with the system working, modify things, add features, fix bugs, and try to get it into a state where it works again. Testing that is not trivial, and I'm not (cannot be, there are time constraints for manual tests and our auto-testing is unfortunately non-existant) overly thorough in this regard. Getting to 10k commits will take 50 years this way. I wonder under which circumstances "micro-commits" are a good idea? Admittedly our system isn't

    • Re: (Score:2)

      by joey ( 315 )

      One commit per tested bugfix. One commit per semi-tested feature. One commit per update to design spec. One commit per update to docs (if not included in a feature/bugfix commit). Also, one merge commit per non-fastforward, non-rebased merge from a feature or bugfix branch can easily bloat the numbers. Plus you can choose to make multiple commits while within those branches, which both bloats the numbers greatly, and helps with backing out if you get into that broken state you mention and can't find your wa

    • Re: (Score:2)

      by mgiuca ( 1040724 )

      Under all circumstances are "micro-commits" a good idea. The only reason not to commit in small increments is if you are working on something that will break your code until it's finished. For that, you should be using a branch, and doing micro-commits on the branch, then finally merge the branch back when you're done.

      Why? The main reason is that if something is broken ("huh? That was working before, now it isn't!"), you will be able to go back and bisect. Find the last commit where it was working and the f

  • And in only 10,000 more it will be possible to actually administer the damn thing. I swear Drupal is a really powerful project, but if you have ever tried to train non-tech savvy people to run the backend you know an unspeakable pain.

Slashdot Top Deals

Real programmers don't comment their code. It was hard to write, it should be hard to understand.

Close