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

Comments

Depends on commit style

[imsabbel]

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

Re:Depends on commit style

[buchner.johannes]

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:Depends on commit style

[gl4ss]

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

Re:Depends on commit style

[WuphonsReach]

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.

Re:Depends on commit style

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

Linus Torvalds?

[nlewis]

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

Re:Linus Torvalds?

[nadaou]

Here you go-

Linux Kernel 2.6 - Linus.Torvalds - Commits: 10034

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

10034 > 10000.

pre2.6: more.

Re:ffmpeg et al

[jisom]

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.

Sure

[Anonymous Coward]

Can anyone claim more?

I can claim whatever you want.

Re:Sure

[TheRaven64]

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.

Yes, Jim Meyering on coreutils

[James Youngman]

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

Re:Yes, Jim Meyering on coreutils

[madhusudancs]

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

Re:Yes, Jim Meyering on coreutils

[sqldr]

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

Re:ffmpeg et al

[pookemon]

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

Get out your rulers!

[Anonymous Coward]

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

Re:Get out your rulers!

[gl4ss]

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)

Re:ffmpeg et al

[muphin]

note: For a "SINGLE" Author

10.000 commits

[CharlyFoxtrot]

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

Re:10.000 commits

[M0j0_j0j0]

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

Re:10.000 commits

[gmhowell]

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

Why commit to a hypergamous harlot?

Re:10.000 commits

[mug funky]

apparently men and women understand sarcasm equally.

i'm not sure what that makes you.

Re:10.000 commits

[DarwinSurvivor]

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

Quality over quantity

[nurb432]

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

Re:Quality over quantity

[l0ungeb0y]

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.

In other news...

[NonUniqueNickname]

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:In other news...

[m50d]

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

[jcam2]

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

Re:Webmin commits

[AvitarX]

Thank you.

Re:Webmin commits

[SomePgmr]

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.

ikiwiki: 10262

[joey]

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.

Re:ffmpeg et al

[F.Ultra]

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

Software as a form of publication.

[__aapopf3474]

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.

Re:Software as a form of publication.

[tgeller]

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.

Re:Software as a form of publication.

[tgeller]

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

FreeSWITCH

[grahamsaa]

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.

Re:FreeSWITCH

[grahamsaa]

facepalm. His last name is spelled Minessale.

Re:ffmpeg et al

[muphin]

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

I use GIT as my "auto-save" cloud.

[VortexCortex]

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.

Re:I use GIT as my "auto-save" cloud.

[pookemon]

Is it open source?

Re:I use GIT as my "auto-save" cloud.

[WuphonsReach]

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

Re:I use GIT as my "auto-save" cloud.

[tequila13]

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

Gentoo Statistics

[Robbat2]

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

Re:Gentoo Statistics

[miknix]

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

Re:ffmpeg et al

[pookemon]

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

The Eclipse Project

[aniefer]

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

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

Re:The Eclipse Project

[mandelbr0t]

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

# of Commits is a horrible metric

[syousef]

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.

Re:# of Commits is a horrible metric

[phantomfive]

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

Re:# of Commits is a horrible metric

[TheRaven64]

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.

Re:# of Commits is a horrible metric

[bjourne]

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.

quality not quantity

[Anonymous Coward]

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

Re:quality not quantity

[joey]

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

Re:Come review time...

[The Dawn Of Time]

Have you time-traveled from the 70s?

...but

[malloc]

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

Can anyone claim more? Two words...

[fred911]

Anonymous Coward

Milo

[CentTW]

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.

Commit numbers don't mean quality

[laffer1]

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.

Re:A little over 30K on ohloh

[sabre]

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

Reindent the code

[Aceticon]

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.

Re:Come review time...

[Hognoxious]

Yes, it took me forty years to get here.

Is Gary Glitter still topping the charts?

samba / tng project

[lkcl]

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.

Re:Come review time...

[ciderbrew]

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.

Why / how?

[harmonica]

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.

Re:Why / how?

[joey]

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,

Re:Why / how?

[mgiuca]

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.

In just 10,000 more....

[datapharmer]

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.

Re:ffmpeg et al

[tehcyder]

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

ur mum's face is a ffmpeg