Re: git as an sfc member project

From: Jeff King <peff@peff.net>
Date: Oct 23, 2010, 13:39 UTC
Message-ID: <20101023133948.GA2002@sigill.intra.peff.net>
In-Reply-To: <AANLkTikxMtdvppLur4kuXffRn0G29NFv6ameTpaeY46G@mail.gmail.com>

On Sat, Oct 23, 2010 at 11:52:26AM +0000, Ævar Arnfjörð Bjarmason wrote:

> Either way it doesn't matter, since I'm not interested in being a SFC
> liasion. I just want to hack, not deal with issues like these (but
> more power to people who want to).

I didn't mean to pick on you, btw. It's just that I was surprised to see you, whose first commit was only 6 months ago, in the list of top contributors by lines of code. You're productive, but not _that_ productive. :)

As it turns out, even though Junio's numbers are doubled, you are in fact high by line count. It's because of compat/regex:

  $ git log --pretty=format: --numstat --author=Bjarmason compat/regex/* |
    perl -ne '/^\d+/ and $total += $&; END { print "$total\n"; }'
  11186

which accounts for 85% of your contribution. :)

Show 7 quoted lines

> But I think picking people for anything based on the number of lines
> that git-blame thinks people "own" is a bad criteria. My contributions
> to Git are relatively small, but I've happened to pick projects (the
> test suit, gettext) that have touched a lot of lines of code.
> 
> But other people who've done 10x more work than I have (both in time &
> importance) probably have 10x less lines of code assigned to them.

I think counting surviving lines via git-blame is not that bad a metric for importance. It's certainly better than counting added lines (as I did above), as it measures lines that people are actually still using. The problem here is that we have quite large chunks of "uninteresting". Junio made some attempt to account for this by counting various parts of the codebase separately. Probably compat/ should have been removed from the core count (ditto for Marius Storm-Olsen, whose line count is inflated by importing nedmalloc; which isn't to say that any of these contributions aren't important. They just aren't the same as sitting down and writing 10,000 lines of custom git code).

In general, any line count of code (surviving or otherwise) will favor people who are adding features rather than fixing bugs. I prefer commit count, where I personally fare much better. :)

One interesting metric to me is the ratio of commit log lines to code lines. A high ratio implies (to some degree) working on bugfixes, where the actual changed lines of code are less important than the time you spend figuring out _which_ lines to change.

You can measure it with something like:

  $ git log  --format='Author: %an%n%w(0,4,4)%B' --numstat --no-merges |
    perl -ne '
      if (/^Author: (.*)/) { $author = $1 }
      elsif (/^\s{4}.+/) { $commit{$author}++ }
      elsif (/^\d+/) { $code{$author} += $& }
      END {
        print($commit{$_} / $code{$_}, " $_\n")
          for grep { $code{$_} } keys(%code)
      }
    ' | sort -rn

Of course it has its own set of flaws. One giant feature contribution can outweight a lot of bugfixes in the average.

-Peff