Slashdot Mirror


10,000 Commits To an Open-source Project

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?"

101 comments

  1. Come review time... by Anonymous Coward · · Score: 0

    we're going to base your salary on lines of code committed. Why is this news?

    1. Re:Come review time... by The+Dawn+Of+Time · · Score: 1

      Have you time-traveled from the 70s?

    2. Re:Come review time... by Hognoxious · · Score: 1

      Yes, it took me forty years to get here.

      Is Gary Glitter still topping the charts?

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    3. Re:Come review time... by ciderbrew · · Score: 1

      Yes, he's is in the top 10 of people to keep your kids away from. He moved up a spot since Michael Jackson died. I'm sorry didn't you know he was dead? You wouldn't have recognised him anyway.

  2. ffmpeg et al by mug+funky · · Score: 0

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

    1. Re:ffmpeg et al by jisom · · Score: 2

      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.

    2. Re:ffmpeg et al by pookemon · · Score: 1

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

      --
      dnuof eruc rof aixelsid
    3. Re:ffmpeg et al by muphin · · Score: 1

      note: For a "SINGLE" Author

      --
      It's not a typo if you understood the meaning!
    4. Re:ffmpeg et al by mug+funky · · Score: 0

      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.

    5. Re:ffmpeg et al by F.Ultra · · Score: 1

      note that he said that he mostly commited pathes from others. So Linus Torvalds would beat him by a mile.

    6. Re:ffmpeg et al by muphin · · Score: 1

      i was referring to the # 26402 patches/comits could be from multiple authors.

      --
      It's not a typo if you understood the meaning!
    7. Re:ffmpeg et al by pookemon · · Score: 1

      Even the summary says that it's not a single author - he's committing (mostly) other peoples work - big deal.

      --
      dnuof eruc rof aixelsid
    8. Re:ffmpeg et al by Anonymous Coward · · Score: 0

      pfft... Jean Valjean committed 24601 while in prison...

    9. Re:ffmpeg et al by tehcyder · · Score: 2

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

      ur mum's face is a ffmpeg

      --
      To have a right to do a thing is not at all the same as to be right in doing it
  3. Depends on commit style by imsabbel · · Score: 1

    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...

    --
    HI O WISE PRINCE. WHT TOOK U SO DAM LONG?
    1. Re:Depends on commit style by buchner.johannes · · Score: 1

      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"

      --
      NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
    2. Re:Depends on commit style by gl4ss · · Score: 1

      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 saves he should have something more than just rather basic functionality. nobody cares about a patch that adds some new sub-function(or method, or whatever you want to call subroutines), what people care is the patch that makes that sub routine work(unless the version tracking is used as source sharing, in that case it's just as useful as any shared document, it makes it easier to explain how someone should start his part of the project).

      --
      world was created 5 seconds before this post as it is.
    3. Re:Depends on commit style by WuphonsReach · · Score: 1

      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 custom non-programming work, whenever I finish a significant step in a process.

      Doing commits every 5 minutes is probably too often, doing commits once a week is way too long (potentially losing multiple days worth of work). And I constantly argue against "end-of-day" commits because those tend to have the worst commit messages.

      I suggest committing when:
      - You are getting up to stretch. Because after your mini-break, you won't remember enough detail to document why you made the change.
      - You've addressed a specific bug or collection of small bugs / changes.
      - You've finished a task / reached a natural break point and want to save your progress.

      --
      Wolde you bothe eate your cake, and have your cake?
    4. Re:Depends on commit style by Anonymous Coward · · Score: 1

      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 file at a time and other such nonsense which takes a single change and splits it into many. For example if you add a you intend to export function you should add the function in both your header and source file at the same time in one transaction. Splitting it up into one commit for the header and one commit for the source file is pointless. They're both part of the same change.

      There really isn't much of a point to bunching up 50 small changes which have nothing to do with each other other than they're all small. Often small changes in source can effect much bigger changes in behavior. Changing a constant, changing a loop's test condition, or fixing an "off by one" bug are just a few examples where a "only a few characters" effect a significant change in behavior. Also there are times where it takes a significant amount of time to detect a problem that gets fixed with a few characters. A change of few characters does not always correlate to small effort expended or not worth doing.

  4. Linus Torvalds? by nlewis · · Score: 1

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

    1. Re:Linus Torvalds? by Anonymous Coward · · Score: 0

      6583 since switching to git. He was a more active committer before the git switch over so I'd guess 10,000 from that period.

    2. Re:Linus Torvalds? by nadaou · · Score: 4, Informative

      Here you go-

      Linux Kernel 2.6 - Linus.Torvalds - Commits: 10034

      http://www.ohloh.net/p/linux/contributors

      10034 > 10000.

      pre2.6: more.

      --
      ~.~
      I'm a peripheral visionary.
    3. Re:Linus Torvalds? by Anonymous Coward · · Score: 0

      Linux > Drupal.

    4. Re:Linus Torvalds? by Anonymous Coward · · Score: 0

      Linus? Bah.

      Commits don't count when you built your own, awesome, dvcs to do them in ;)

      p.s.: Drupal uses git too.

  5. Sure by Anonymous Coward · · Score: 2, Insightful

    Can anyone claim more?

    I can claim whatever you want.

    1. Re:Sure by Anonymous Coward · · Score: 0

      Can anyone claim more?

      I can claim whatever you want.

      If you could claim that you were the one who got a little bit tipsy last night, "borrowed" a boat and crashed it into the dock before drunkenly stumbling home, that would be extremely helpful. Thanks!

    2. Re:Sure by TheRaven64 · · Score: 1
      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 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 the top 2,000 open source developers, and yet my total commit count is a bit under 2,000, so I guess it depends on your commit style. I have a habit of committing 'rewrote this subsystem' type patches when I'm working on functionality improvements, but bug fixes tend to get their own commit even if they're only a few characters of changes.

      --
      I am TheRaven on Soylent News
  6. Yes, Jim Meyering on coreutils by James+Youngman · · Score: 4, Informative

    ~/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

    1. Re:Yes, Jim Meyering on coreutils by madhusudancs · · Score: 1

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

    2. Re:Yes, Jim Meyering on coreutils by sqldr · · Score: 1

      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!!!

      --
      I wrote my first program at the age of six, and I still can't work out how this website works.
  7. Get out your rulers! by Anonymous Coward · · Score: 4, Funny

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

    1. Re:Get out your rulers! by mug+funky · · Score: 0

      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.

    2. Re:Get out your rulers! by Anonymous Coward · · Score: 0

      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.

      Did that for you!

    3. Re:Get out your rulers! by Anonymous Coward · · Score: 0

      Thanks for letting me know so I could mod them back up!

    4. Re:Get out your rulers! by gl4ss · · Score: 1

      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)

      --
      world was created 5 seconds before this post as it is.
  8. 10.000 commits by CharlyFoxtrot · · Score: 5, Funny

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

    --
    If all else fails, immortality can always be assured by spectacular error.
    1. Re:10.000 commits by M0j0_j0j0 · · Score: 2

      They can , but they commit with more than one project, so it will be hard to track the ubar author here.

    2. Re:10.000 commits by gmhowell · · Score: 1

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

      Why commit to a hypergamous harlot?

      --
      Jesus was all right but his disciples were thick and ordinary. -John Lennon
    3. Re:10.000 commits by Anonymous Coward · · Score: 0

      We can. We just don't care, as you'll come back anyway. :P
      Proof 1: You always run back to the dick who beat you up the week before.
      Proof 2: Who built the moon rocket? :P

      Oh, and I loove and respect smart girls. It's just... you're not one of them. :P

      P.S.: You're a man? Wrong! You may think you are, but a man would never have written parent comment! ^^

    4. Re:10.000 commits by mug+funky · · Score: 1

      apparently men and women understand sarcasm equally.

      i'm not sure what that makes you.

    5. Re:10.000 commits by DarwinSurvivor · · Score: 1

      Sure they both understand it equally, just not very well.

  9. Quality over quantity by nurb432 · · Score: 1

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

    --
    ---- Booth was a patriot ----
    1. Re:Quality over quantity by l0ungeb0y · · Score: 1

      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 manage to properly auto-construct a freaking database connection dsn, why the hell would I entrust them to provide a secure service? So Drupal can take it's 10,000 commits and shove them up their ass. If the had quality coders creating good work, I'm confident they'd have a fraction of the commits they currently do.

    2. Re:Quality over quantity by Anonymous Coward · · Score: 0

      Looks like this was fixed a year ago.

  10. In other news... by NonUniqueNickname · · Score: 3, Insightful

    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.

    1. Re:In other news... by m50d · · Score: 1

      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.

      --
      I am trolling
  11. Webmin commits by jcam2 · · Score: 2

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

    1. Re:Webmin commits by AvitarX · · Score: 1

      Thank you.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    2. Re:Webmin commits by Anonymous Coward · · Score: 0

      Webmin owns. I don't know what you work on exactly, but the stack frames generated from my clicks probably went into code paths you've written at some point.

      Thanks,

    3. Re:Webmin commits by SomePgmr · · Score: 1

      You just made me revisit Webmin after something like 10 years! Thanks for all your hard work, I think I'm going to give it a spin again.

    4. Re:Webmin commits by Anonymous Coward · · Score: 0

      Does it handle dynamic DNS yet without screwing up when a record is added between loading the page and hitting delete yet?

      Currently the core version doesn't have a dynamic DNS module, and the addon module changes things by position. Makes it very dangerous to use.

  12. ikiwiki: 10262 by joey · · Score: 3, Informative

    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.

    --
    see shy jo
  13. Software as a form of publication. by __aapopf3474 · · Score: 4, Interesting

    I have 30874 on the Ptolemy II repository, see http://www.ohloh.net/accounts/cxbrx. Hauke Fuhrmann put up Codeswarm videos of the software evolution of the Ptolemy II project. See Chaotic, Less Chaotic. 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.

    1. Re:Software as a form of publication. by tgeller · · Score: 2

      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.

      --
      Tom Geller
    2. Re:Software as a form of publication. by Anonymous Coward · · Score: 0

      I don't fault you for your intent, it was obviously a light-hearted kudos to open source in general. However maybe you should be punished for not knowing that it would cause an immature dick measuring fiasco. Although having to read this thread is probably punishment enough.

      I say thanks for the intent and thanks to all of the open source committers and supporters, however long... I mean however many commits they have made.

    3. Re:Software as a form of publication. by tgeller · · Score: 1

      Oh, no worries. I've been on /. long enough to know that everything becomes a dick-measuring fiasco. ;)

      --
      Tom Geller
  14. FreeSWITCH by grahamsaa · · Score: 1

    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.

    --
    Facts have a liberal bias.
    1. Re:FreeSWITCH by grahamsaa · · Score: 1

      facepalm. His last name is spelled Minessale.

      --
      Facts have a liberal bias.
  15. I use GIT as my "auto-save" cloud. by VortexCortex · · Score: 1

    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.

    1. Re:I use GIT as my "auto-save" cloud. by pookemon · · Score: 1

      Is it open source?

      --
      dnuof eruc rof aixelsid
    2. Re:I use GIT as my "auto-save" cloud. by WuphonsReach · · Score: 1

      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.)

      --
      Wolde you bothe eate your cake, and have your cake?
    3. Re:I use GIT as my "auto-save" cloud. by tequila13 · · Score: 1

      80.000 commits and your first backup will be made a month from now? Hmm..

  16. Gentoo Statistics by Robbat2 · · Score: 1

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

    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

    --
    ICQ# : 30269588
    "I used to be an idealist, but I got mugged by reality."
    1. Re:Gentoo Statistics by miknix · · Score: 1

      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.

      That's impressive and we don't even count what's going on in the overlays..

  17. thousands or millions? by Anonymous Coward · · Score: 0

    KDE is @ > 1.2 millions revisions --> http://websvn.kde.org/

  18. *yawn* by Anonymous Coward · · Score: 0

    http://www.oxide.org/cvs/deraadt.html

    23680 actual commits not that linus horseshit. several people in openbsd have > 10000 so whatever...

  19. 99% of the commits are simple code beautifications by Anonymous Coward · · Score: 0

    From a quick analysis of the check-ins, it seems most of them are white-space removal, code formatting etc type changes.

    Where I work, people that make those kinds of commits are known as busy-workers. Their objective is to convey the fact that they're doing work, when in reality they're not doing anything at all, they all somehow end-up in management.

  20. The Eclipse Project by aniefer · · Score: 1

    Dani Megert : 14,143 commits on Eclipse Platform + JDT

    Darin Wright : 12,642 commits on Eclipse Platform + JDT

    1. Re:The Eclipse Project by mandelbr0t · · Score: 1

      This is still one of the best open-source projects out there. My thanks to such dedicated contributors.

      --
      "Please describe the scientific nature of the 'whammy'" - Agent Scully
  21. # of Commits is a horrible metric by syousef · · Score: 4, Insightful

    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.

    --
    These posts express my own personal views, not those of my employer
    1. Re:# of Commits is a horrible metric by phantomfive · · Score: 1

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

      --
      "First they came for the slanderers and i said nothing."
    2. Re:# of Commits is a horrible metric by TheRaven64 · · Score: 1

      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 sure what a good metric would be. Lines of code added is pretty bad. Some of my best changes have been reducing the total amount of code. I recently tidied up some of my code in clang - no functionality changes, but about 600 lines of code less to think about, and a better structure to maintain in the future. If you count lines of code added as the metric, then this patch would have had a negative impact.

      Ohloh uses number of lines changed, but that means I get as much credit for removing a trailing space as I do for writing a line of code, so people who want good Ohloh rankings have a habit of submitting lots of style-fixing patches.

      --
      I am TheRaven on Soylent News
    3. Re:# of Commits is a horrible metric by bjourne · · Score: 2

      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 reason why is because the code they produce is confusing and deservedly hard to explain.

  22. quality not quantity by Anonymous Coward · · Score: 1

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

    1. Re:quality not quantity by joey · · Score: 1

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

      --
      see shy jo
  23. ohloh.net counts these things for you by Anonymous Coward · · Score: 0

    ohloh.net counts these things for you. For example:

    http://www.ohloh.net/p/coreutils/contributors

  24. ...but by malloc · · Score: 1

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

    --
    ___________________ I want to be free()!
    1. Re:...but by Anonymous Coward · · Score: 0

      He didn't say "back up the claim with facts and evidence". I can claim I'm a leprechaun. Ask me to prove it and I might not be able to.

  25. Can anyone claim more? Two words... by fred911 · · Score: 1

    Anonymous Coward

    --
    09 F9 11 02 9D 74 E3 5B - D8 41 56 C5 63 56 88 C0 45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  26. Milo by CentTW · · Score: 1

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

  27. Character Commits by Anonymous Coward · · Score: 0

    I commit after every character!

  28. Commit numbers don't mean quality by laffer1 · · Score: 1

    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

    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.

  29. And that's a good thing ?? by xushi · · Score: 0

    Why is he boasting? The more commits needed or happening means the shittier and shittier his code is (or lacking) where it requires more and more patches/fixes to get it right...

  30. 89559 Commits by Anonymous Coward · · Score: 0

    by Ruediger Timm
    http://www.libreoffice.org/about-us/credits/

  31. A little over 30K on ohloh by Anonymous Coward · · Score: 0

    Ohloh doesn't have full version control history, but it does show a little over 30K commits to LLVM and Clang compilers:

    Time flies when you're having fun!

    -Chris

    1. Re:A little over 30K on ohloh by sabre · · Score: 1

      Lets try this again, logged in:

      Ohloh doesn't have full version control history, but it does show a little over 30K commits to the LLVM and Clang compilers:

      Time flies when you're having fun!

      -Chris

  32. It's not that much by Anonymous Coward · · Score: 0

    David Faure from KDE has 31604 commits in the CVS/subversion era only; I haven't counted his git commits.

  33. Reindent the code by Aceticon · · Score: 1

    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 number of commits, thus crossing the magic 10k number.
    - You continue receiving goatse e-mails.

  34. samba / tng project by lkcl · · Score: 1

    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.

  35. Who cares? its not an important metric by Anonymous Coward · · Score: 0

    Seriously if anyone thinks this is an important metric they should get their ruler out and measure the size of their cock, then go out an buy a Porsche and an SUV with a large V8 engine.

  36. Grammar nazi commits suicide by Anonymous Coward · · Score: 0

    Commit is a verb, not a noun

  37. OpenBSD by Anonymous Coward · · Score: 0

    Theo de Raadt: >20000
    Marc Espie > 10000

  38. Why / how? by harmonica · · Score: 1

    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 FOSS, but a lot of FOSS projects are complex, some certainly more complex than what we do.

    1. Re:Why / how? by joey · · Score: 1

      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 way out.

      Also, you can get seriously more productive by increasing your iteration rate. No matter what resources need to be thrown at the test infrastructure etc to allow an increase. This is why Debian, which used to iterate once a day, now pushes out updates to unstable 6 times a day (with CD builds etc) and testing 2, IIRC,

      --
      see shy jo
    2. Re:Why / how? by mgiuca · · Score: 1

      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 first commit where it was broken. Now to figure out what broke it. Would you rather that commit be a few dozen lines which are all closely related to the same thing ("of course, it was the froobler that broke"), or a multi-thousand line diff that changed every conceivable part of the program, messed around with indentation, and generally has no common theme to the changes, and has a commit log "done for the day; committing" ("wow, I have no idea what that commit did")? The answer for all projects of all sizes is the former.

      In particular, a new feature and a bug fix should never appear together in a commit. New features are often large, and often introduce new bugs, but bug fixes should be careful and small. That way, you separate out the fixes from the potential problems. Also in open source it's important for bug fixes to have independent commits, because distro maintainers will often cherry-pick the fixes for immediate distribution, but they don't want to distribute the new features as well.

  39. In just 10,000 more.... by datapharmer · · Score: 1

    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.

    --
    Get a web developer
  40. Who gives a fuck? by Anonymous Coward · · Score: 0

    Seriously. Who gives a fuck? What is this, dick-measuring for nerds?

  41. Alexandre Julliard of wine by Anonymous Coward · · Score: 0

    Alexandre Julliard of the wine project has way over 10000 commits.