Blog Entries

September 2019
« May    

When Git Push Comes To Shove

[If you are not familiar with the English idiom "When push comes to shove" you can read more here.]

For some time I have been hesitant to start publishing data about usage of Git. You see, when a community changes a tool as fundamental as the SCM it will need to change its processes (to some degree). Of course, this is often the reason why the SCM has been switched. It is also the first reason why it is difficult to compare SVN data from “before” to Git data from “after”. Reason 2 is that the two systems work in very different ways. A commit in a DVCS is very different from a commit in a centralised system. It is probably the “push” that is more comparable. Right? Right??

Let’s take a look at the daily commits for KDEPIM:

KDEPIM switched to Git on 28 January, 2011 (or thereabouts). Before this date the average daily commits was 16 (14 in the month prior), after it drops to 11. I’m sure the KDEPIM community is not crying into its collective beer tonight. Here’s why:

  • Human factor: The initial large drop in commit rate could easily be caused by people needing to learn how to use Git properly.
  • Process factor: Git allows the user to squash multiple commits into one.

The change of tool will always have human and process impacts. Here I have suggested just one of each; there are many more. But these factors plausibly explain my concern with coming forward with Git data… It is up to me to make it absolutely clear why (or potentially why) the figures change in the way that they do. Whilst the need for education and commit squashing are two factors that might apply to any project, the factors that actually apply can only really be revealed by those directly involved.

So what can we conclude? Two things:

  1. The impact of the switch to Git can be shown in the measurement of something as simple as daily commits;
  2. Watching the new trends develop over time is going to be fascinating.
Be Sociable, Share!

3 comments to When Git Push Comes To Shove

  • hmmm

    Do you think that some metric such as “number of lines of code changed/touched” per period of time would be an appropriate metric? This would be some metric which one could apply before and after the transition, and therefore isolate the VCS factor.

    Also, as git is distributed, it might be the case that many commits happen in the private clones before being pushed. Is it possible to get these?

    Basically, I find these visualisations fascinating, and they always make me hungry for more ;)

  • Alex

    I think I’d use the number of commits, not the number of pushes.
    But it’s hard to say.
    With git, I often group multiple commits in one push. Sometimes those single commits are smaller than what I would have done with svn, but actually they shouldn’t, IOW also with svn the commits should be as fine-grained as they are with git.


    P.S. can you make a list of contributors, sorted by the number of weeks in which they committed ?

  • Each Linux release Jonathan Corbet or Greg KH are publishing some statistics about git commits on You could rich out to them asking for scripts they are using.

    > P.S. can you make a list of contributors, sorted by the number of weeks in which they committed?

    You can use “git log –pretty=format:’%ai %an ” to get an easily parseable list of commits with date and author only. “%ai” is an “author date” which may be different from “%ci” which is a “committer date” — choose one that makes more sense to you.