git/list[1] front-page[2] threads[3] people[4] search[5] about
 

git version statistics

From
Jeff King <peff@peff.net>
Date
May 31, 2012, 11:48 UTC
Message-ID
<20120531114801.GA21367@sigill.intra.peff.net>

Just for fun, I've assembled a few statistics on git client versions that hit github.com. These are collected from the http user-agent strings provided by smart-http requests (we don't allow dumb http at all these days, and the git protocol does not provide any version information). It includes only the git/* entries (which are the vast majority of clients hitting "info/refs?service=.*"; the second biggest is JGit/*). And I counted each version only a single time from each IP (so this would skew if you had a lot of clients behind a single IP; their version would be counted only once).

Here are the results from the last few days:
  git/1.7.11.x |  0.1%   (0%) | 
  git/1.7.10.x | 21.1%  (21%) | **********************************
  git/1.7.9.x  | 11.4%  (32%) | ******************
  git/1.7.8.x  | 24.1%  (56%) | ****************************************
  git/1.7.7.x  | 12.2%  (68%) | ********************
  git/1.7.6.x  |  1.8%  (70%) | **
  git/1.7.5.x  |  8.2%  (78%) | *************
  git/1.7.4.x  |  7.2%  (86%) | ***********
  git/1.7.3.x  |  1.9%  (87%) | ***
  git/1.7.2.x  |  3.0%  (90%) | ****
  git/1.7.1.x  |  2.1%  (93%) | ***
  git/1.7.0.x  |  7.0%  (99%) | ***********
  git/1.6.6.x  |  0.0% (100%) | 

In this table, I've collapsed all of the x.y.z.* versions into a single string to get an overview (a more detailed table is below). The first percentage is the portion of the total requests; the second is a cumulative portion (so, for example, 90% of clients are running v1.7.2.x or higher, though only 3% are running v1.7.2.x itself).

Note that these numbers are skewed away from git versions lower than v1.6.6, because that is when we added smart http support. Requests over git:// or ssh are not included at all in these results.

For comparison, here's the same table from mid-September of 2011 (v1.7.7 was in -rc1 at the time):

  git/1.7.7.x |  0.2%   (0%) | 
  git/1.7.6.x | 19.3%  (19%) | *****************
  git/1.7.5.x |  8.0%  (27%) | *******
  git/1.7.4.x | 43.8%  (71%) | ****************************************
  git/1.7.3.x | 10.7%  (82%) | *********
  git/1.7.2.x |  4.9%  (86%) | ****
  git/1.7.1.x |  4.7%  (91%) | ****
  git/1.7.0.x |  8.2%  (99%) | *******
  git/1.6.6.x |  0.1% (100%) | 

So it seems that a large proportion of git users (or at least github users) stay within a few versions of the most current. In both cases, 70% are within 4 major releases of the most recent version.

Here's a more detailed table (from recent data), showing individual w.x.y.z versions:

  git/1.7.10.3 |  3.6%   (3%) | *******
  git/1.7.10.2 |  4.4%   (8%) | *********
  git/1.7.10.1 |  1.5%   (9%) | ***
  git/1.7.10   |  2.4%  (11%) | *****
  git/1.7.9.6  |  0.2%  (12%) | 
  git/1.7.9.5  |  9.2%  (21%) | *******************
  git/1.7.9.4  |  1.2%  (22%) | **
  git/1.7.9.3  |  0.3%  (22%) | 
  git/1.7.9.2  |  0.4%  (23%) | 
  git/1.7.9.1  |  0.4%  (23%) | 
  git/1.7.9    |  1.1%  (24%) | **
  git/1.7.8.6  |  0.3%  (25%) | 
  git/1.7.8.5  |  0.0%  (25%) | 
  git/1.7.8.4  |  0.7%  (25%) | *
  git/1.7.8.3  | 12.2%  (38%) | *************************
  git/1.7.8.2  | 18.8%  (56%) | ****************************************
  git/1.7.8.1  |  0.1%  (56%) | 
  git/1.7.8    |  0.3%  (57%) | 
  git/1.7.7.6  |  0.5%  (57%) | *
  git/1.7.7.4  |  0.2%  (57%) | 
  git/1.7.7.3  |  0.4%  (58%) | 
  git/1.7.7.2  |  0.1%  (58%) | 
  git/1.7.7.1  |  0.0%  (58%) | 
  git/1.7.7    |  0.7%  (59%) | *
  git/1.7.6.5  |  0.1%  (59%) | 
  git/1.7.6.4  |  0.2%  (59%) | 
  git/1.7.6.3  |  0.0%  (59%) | 
  git/1.7.6.1  |  0.5%  (59%) | *
  git/1.7.6    |  0.7%  (60%) | *
  git/1.7.5.4  | 10.9%  (71%) | ***********************
  git/1.7.5.3  |  0.1%  (71%) | 
  git/1.7.5.2  |  0.1%  (71%) | 
  git/1.7.5.1  |  0.2%  (71%) | 
  git/1.7.5    |  0.1%  (71%) | 
  git/1.7.4.5  |  0.4%  (72%) | 
  git/1.7.4.4  |  3.3%  (75%) | *******
  git/1.7.4.3  |  0.0%  (75%) | 
  git/1.7.4.2  |  0.0%  (75%) | 
  git/1.7.4.1  |  5.3%  (81%) | ***********
  git/1.7.4    |  0.2%  (81%) | 
  git/1.7.3.5  |  0.2%  (81%) | 
  git/1.7.3.4  |  1.2%  (82%) | **
  git/1.7.3.3  |  0.1%  (82%) | 
  git/1.7.3.2  |  0.4%  (83%) | 
  git/1.7.3.1  |  0.1%  (83%) | 
  git/1.7.3    |  0.1%  (83%) | 
  git/1.7.2.5  |  3.6%  (86%) | *******
  git/1.7.2.3  |  0.3%  (87%) | 
  git/1.7.2.2  |  0.1%  (87%) | 
  git/1.7.2.1  |  0.0%  (87%) | 
  git/1.7.2    |  0.1%  (87%) | 
  git/1.7.1.1  |  0.1%  (87%) | 
  git/1.7.1    |  2.8%  (90%) | ******
  git/1.7.0.6  |  0.0%  (90%) | 
  git/1.7.0.5  |  0.0%  (90%) | 
  git/1.7.0.4  |  7.0%  (97%) | **************
  git/1.7.0    |  2.6%  (99%) | *****
  git/1.6.6    |  0.0% (100%) | 

The interesting thing to me is how spiky it is, and where the spikes fall. I would expect to see a spike around the highest maint release of each major version (so v1.7.8.6, for example, with many fewer installs of v1.7.8.5, v1.7.8.4, and so forth). But that's not what happens. The most popular v1.7.8.x versions are .3 and .2, and hardly anybody bothered to move to v1.7.8.6.

I can only assume these are skewed by some widely-used binary distribution being locked onto particular versions (e.g., the spike at v1.7.2.5 represents Debian stable).

If anybody has suggestions for other interesting analyses to perform, let me know.

-Peff
Next: Jeff King
Message 1 of 84 in “git version statistics”
  1. Jeff KingMay 31, 2012
  2. Jeff KingMay 31, 2012
  3. Junio C HamanoMay 31, 2012
  4. Jeff KingJun 1, 2012
  5. Junio C HamanoJun 1, 2012
  6. Jeff KingJun 2, 2012
  7. Tomas CarneckyJun 2, 2012
  8. Jeff KingJun 2, 2012
  9. 1/4 move git_version_string into version.cJeff King, Jun 2, 2012
  10. 2/4 version: add git_user_agent functionJeff King, Jun 2, 2012
  11. Thomas RastJun 19, 2012
  12. Jeff KingJun 19, 2012
  13. Jeff KingJun 19, 2012
  14. 1/3 Makefile: apply dependencies consistently to sparse/asm targetsJeff King, Jun 19, 2012
  15. Junio C HamanoJun 19, 2012
  16. 2/3 Makefile: split GIT_USER_AGENT from GIT-CFLAGSJeff King, Jun 19, 2012
  17. Junio C HamanoJun 19, 2012
  18. 3/3 Makefile: split prefix flags from GIT-CFLAGSJeff King, Jun 19, 2012
  19. Junio C HamanoJun 19, 2012
  20. Jeff KingJun 19, 2012
  21. Junio C HamanoJun 19, 2012
  22. Jeff KingJun 19, 2012
  23. Junio C HamanoJun 19, 2012
  24. Jeff KingJun 19, 2012
  25. 0/8 makefile cleanupsJeff King, Jun 19, 2012
  26. 1/8 Makefile: apply dependencies consistently to sparse/asm targetsJeff King, Jun 19, 2012
  27. Jonathan NiederJun 20, 2012
  28. Jeff KingJun 20, 2012
  29. Jonathan NiederJun 20, 2012
  30. Jeff KingJun 20, 2012
  31. Jeff KingJun 20, 2012
  32. 01/11 Makefile: sort LIB_H listJeff King, Jun 20, 2012
  33. Junio C HamanoJun 20, 2012
  34. Jeff KingJun 20, 2012
  35. 02/11 Makefile: fold MISC_H into LIB_HJeff King, Jun 20, 2012
  36. Junio C HamanoJun 20, 2012
  37. Jonathan NiederJun 20, 2012
  38. Jeff KingJun 20, 2012
  39. 5/11 Makefile: fold XDIFF_H and VCSSVN_H into LIB_HJonathan Nieder, Jul 7, 2012
  40. Junio C HamanoJul 9, 2012
  41. Jonathan NiederJul 6, 2012
  42. 03/11 Makefile: do not have git.o depend on common-cmds.hJeff King, Jun 20, 2012
  43. Jonathan NiederJun 20, 2012
  44. 04/11 Makefile: apply dependencies consistently to sparse/asm targetsJeff King, Jun 20, 2012
  45. Jonathan NiederJun 20, 2012
  46. Jeff KingJun 20, 2012
  47. Makefile: document ground rules for target-specific dependenciesJonathan Nieder, Jul 7, 2012
  48. 05/11 Makefile: do not replace @@GIT_USER_AGENT@@ in scriptsJeff King, Jun 20, 2012
  49. Junio C HamanoJun 20, 2012
  50. Jeff KingJun 20, 2012
  51. 06/11 Makefile: split GIT_USER_AGENT from GIT-CFLAGSJeff King, Jun 20, 2012
  52. Jonathan NiederJun 20, 2012
  53. Jeff KingJun 20, 2012
  54. Jonathan NiederJun 20, 2012
  55. 06/11 Makefile: split GIT_USER_AGENT from GIT-CFLAGSJonathan Nieder, Jul 7, 2012
  56. 07/11 Makefile: split prefix flags from GIT-CFLAGSJeff King, Jun 20, 2012
  57. Jonathan NiederJun 20, 2012
  58. Jeff KingJun 20, 2012
  59. 08/11 Makefile: do not replace @@GIT_VERSION@@ in shell scriptsJeff King, Jun 20, 2012
  60. 09/11 Makefile: update scripts when build-time parameters changeJeff King, Jun 20, 2012
  61. 10/11 Makefile: build instaweb similar to other scriptsJeff King, Jun 20, 2012
  62. 11/11 Makefile: move GIT-VERSION-FILE dependencies closer to useJeff King, Jun 20, 2012
  63. Jonathan NiederJun 20, 2012
  64. Jonathan NiederJun 20, 2012
  65. Jeff KingJun 20, 2012
  66. Jonathan NiederJun 20, 2012
  67. Jeff KingJun 20, 2012
  68. Jonathan NiederJun 20, 2012
  69. Automatic dependency tracking in the Git build system (was: Re: [PATCHv2 1/8] Makefile: apply dependencies consistently to sparse/asm targets)Stefano Lattarini, Jun 21, 2012
  70. Junio C HamanoJun 20, 2012
  71. Thomas RastJun 20, 2012
  72. Jeff KingJun 21, 2012
  73. Junio C HamanoJun 21, 2012
  74. 2/8 Makefile: do not replace @@GIT_USER_AGENT@@ in scriptsJeff King, Jun 19, 2012
  75. 3/8 Makefile: split GIT_USER_AGENT from GIT-CFLAGSJeff King, Jun 19, 2012
  76. 4/8 Makefile: split prefix flags from GIT-CFLAGSJeff King, Jun 19, 2012
  77. 5/8 Makefile: do not replace @@GIT_VERSION@@ in shell scriptsJeff King, Jun 19, 2012
  78. 6/8 Makefile: update scripts when build-time parameters changeJeff King, Jun 19, 2012
  79. 7/8 Makefile: build instaweb similar to other scriptsJeff King, Jun 19, 2012
  80. 8/8 Makefile: move GIT-VERSION-FILE dependencies closer to useJeff King, Jun 19, 2012
  81. 3/4 http: get default user-agent from git_user_agentJeff King, Jun 2, 2012
  82. 4/4 include agent identifier in capability stringJeff King, Jun 2, 2012
  83. Stephen BashMay 31, 2012
  84. Jeff KingJun 1, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.