GitSurvey2009

From Git SCM Wiki
Jump to: navigation, search

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated. Please visit git-scm.com/doc for up-to-date documentation.

Git User's Survey 2009 summary

The Git User's Survey 2009 has been closed on September 15, 2009.

The survey could be found here:

This survey was open from 15 July to 15 September 2009 (for 2 months).

You can get raw data (individual responses) for the survey here:

You can use survey_parse_Survs_CSV(num).com.perl script from http://github.com/jnareb/GitSurvey-scripts repository to analyze data from CSV export linked above.

Results of the survey:

There were 3868 individual responses in this survey (the 30 responses in 'test' channel were removed).
There were 3236 individual responses in GitSurvey2008 (including 21 responses in 'test' channel).
There were 683 individual responses in GitSurvey2007.
There were around 117 responses in GitSurvey2006.

Table of contents:

Contents

Information about survey completion

Number of questions answered per responder

Histogram of the number of answered questions by responder
Answered Resp.[n] Resp.[%]
30 29 0.7%
29 129 3.3%
28 247 6.4%
27 439 11.3%
26 606 15.7%
25 681 17.6%
24 504 13.0%
23 418 10.8%
22 210 5.4%
21 116 3.0%
20 84 2.2%
19 53 1.4%
18 31 0.8%
17 30 0.8%
16 22 0.6%
15 32 0.8%
14 26 0.7%
13 13 0.3%
12 6 0.2%
11 5 0.1%
10 3 0.1%
9 2 0.1%
8 3 0.1%
7 0 0.0%
6 0 0.0%
5 0 0.0%
4 4 0.1%
3 2 0.1%
2 4 0.1%
1 7 0.2%
0 162 4.2%


The table above shows histogram of the number of answered questions by responder from the 30 questions in the survey. Most people answered from 23 to 27 questions from 30. Average number of skipped (not answered) questions is 6.7 +/- 5.9.

Note that in one of questions, "22. Did you participate in previous Git User's Surveys?" lack of answer didn't necessarily mean that somebody skipped this question; lack of answer was there answer in itself. There are also optional (well, more optional) 3 free-form essay questions. That makes 26 questions to answer.

Most answered question was "07. I use Git for (check all that apply)" multiple-choice question.

Number of replies per question

Histogram of number of replies per question

The graph above shows histogram of number of replies per question. As you can see the least replied questions were:

  • "12. What tool (or kind of tool) would you like to have Git support in?" (free-form essay question),
  • "19. What features would you like implemented in Git? What features are you missing?" (also free-form essay),
  • "22. Did you participate in previous Git User's Surveys?" (where skipping means simply not participating in previous surveys), and
  • "30. What other comments or suggestions do you have that are not covered by the questions above?" (again free-form essay), and also
  • "28. Which communication channel(s) do you use?" (multiple choice question, without 'other' answer)

Date of response

Histogram of number of responders by date

The graph above shows histogram of number of responders by date (in CET / GMT+1 / +0100 timezone).

There are a few spikes spikes on above Completion Rate Graph; from those the following four spikes are most visible:

  • 15 Jul | 573 respondents / day
  • 21 Jul | 622 respondents / day
  • 27 Jul | 155 respondents / day
  • 13 Aug | 103 respondents / day

(note that those results are slightly different from the ones presented in 'partial summary, part 1' thread mentioned above; this might be possibly the matter of different timezones used).

This survey was announced at the following blogs (note that dates below for blog posts are in local timezone of blog, whatever it is, while Survs.com dates are in survey admin timezone, which is GMT+01:00 / +0100):


Local Date Date URL
July 14th, 2009, 06:34 pm 14 Jul http://gitster.livejournal.com/36139.html
July 15th, 2009 at 4:23 am 15 Jul http://blogs.gnome.org/newren/2009/07/15/git-users-survey-2009
July 15, 2009 - 12:47 pm 15 Jul http://gitlog.wordpress.com/2009/07/15/git-users-survey-2009
July 17, 2009 at 10:40 am 17 Jul http://blog.gitorious.org/2009/07/17/the-git-users-survey
20 Jul 2009 20 Jul http://github.com/blog/460-git-user-s-survey-2009
20 Aug 2009, 10:08 am 20 Aug http://www.ceondo.com/ecte/2009/08/git-survey-2009 (http://www.indefero.net/blog/)
Sep 10, 2009 @ 10:11 AM 10 Sep http://blog.assembla.com/assemblablog/tabid/12618/bid/10431/Bloggers-compare-Git-notes.aspx


"Git User's Survey 2009" was also announced on the following blogs (found via blogsearch):


Local Date Date URL
17th Jul 2009, 8:47 am 17 Jul http://marilyn.frields.org:8080/~paul/wordpress/?p=2632
2009-07-27 27 Jul http://blog.hartwork.org/?p=451
4 Aug 2009, 10:13 04 Aug http://virtualgenius.spaces.live.com/blog/cns!CC3C966FA733667C!811.entry
2009/08/18 18 Aug http://www.debian-news.net/2009/08/18/misc-developer-news-17/


Another quite important channel for finding about this survey was, according to question 19, microblogging platforms such as Twitter, Identi.ca, Plurk, etc.

Local Date Date URL
5:41 PM, Jul 15th 2009 15 Jul http://twitter.com/jhelwig/statuses/2652743883
11:56 PM, Jul 19th 2009 19 Jul http://twitter.com/kevmoo/status/2728027845
12:24 AM, Jul 21st 2009 21 Jul http://twitter.com/github/status/2746745923
6:02 PM, Jul 21st 2009 21 Jul http://twitter.com/howdous/status/2760055856
8:06 PM, Aug 23rd 2009 23 Aug http://twitter.com/scyldinga/status/3495621307
24-Jul-09 00:27:46 UTC 24 Jul http://identi.ca/notice/6906889
24-Jul-09 10:47:50 UTC 24 Jul http://identi.ca/notice/6927573
03-Aug-09 05:36:49 UTC 03 Aug http://identi.ca/notice/7461438


As you can see the announcement on GitHub Blog (and via Twitter: http://twitter.com/github/status/2746745923) correlate with the second spike in responses on 27 July 2009, when we take difference in timezone into account.

It looks like the announcement on Hartwork Blog, part of Planet Gentoo, might be responsible for small spike in responses at 27 July. But it might have been cased by announcement arriving via other channels, see answers to question "29. How did you hear about this Git User's Survey?" below.


Survey statistics

Total respondents: 3868
First response: Jul 15, 2009
Last response: Sep 16, 2009
Open during: 72 days
Average time: 49 minutes

At most often time between responses was below 1 second (the precision of Survs.com response timestamp), while maximum time between responses was slightly more than 12 hours (half a day).

There were 25 responses in the non-default "GitSurvey2009: no cookies, anonymous" channel that required no cookies, and was totally anonymous (no logging of IP address). This was at the cost of not being able to go back to one's responses to correct or complete it.


About you

01. What country do you live in?

(tabularized free-form single line)

This table is sorted alphabetically.


Country Count Perc.
America (possibly USA) 4 0.1%
Argentina 21 0.6%
Armenia 1 0.0%
Australia 121 3.3%
Austria 49 1.3%
Bangladesh 1 0.0%
Belarus 3 0.1%
Belgium 39 1.1%
Brazil 58 1.6%
Bulgaria 6 0.2%
Canada 158 4.4%
Chile 8 0.2%
China 37 1.0%
Colombia 6 0.2%
Costa Rica 4 0.1%
Croatia 7 0.2%
Cuba 2 0.1%
Czech Republic 47 1.3%
Denmark 30 0.8%
Egypt 4 0.1%
El Salvador 1 0.0%
Estonia 9 0.2%
Faroe Islands 1 0.0%
Finland 52 1.4%
France 157 4.3%
Germany 400 11.0%
Gibraltar 1 0.0%
Greece 11 0.3%
Hong Kong 2 0.1%
Hungary 11 0.3%
Iceland 2 0.1%
India 51 1.4%
Indonesia 4 0.1%
Iran 2 0.1%
Ireland 18 0.5%
Israel 22 0.6%
Italy 65 1.8%
Japan 27 0.7%
Kazakhstan 1 0.0%
Korea, Republic of 4 0.1%
Korea (which one?) 1 0.0%
Kyrgyzstan 1 0.0%
Latvia 6 0.2%
Lithuania 10 0.3%
Luxembourg 2 0.1%
Macedonia (former Yugoslav Republic) 3 0.1%
Malaysia 7 0.2%
Malta 1 0.0%
Mexico 13 0.4%
Moldova 4 0.1%
Nepal 3 0.1%
Netherlands 76 2.1%
New Zealand 39 1.1%
Nicaragua 2 0.1%
Norway 63 1.7%
Pakistan 1 0.0%
Panama 1 0.0%
Peru 1 0.0%
Philippines 3 0.1%
Poland 68 1.9%
Portugal 11 0.3%
Romania 22 0.6%
Russian Federation 75 2.1%
Serbia 5 0.1%
Singapore 3 0.1%
Slovakia 4 0.1%
Slovenia 8 0.2%
South Africa 14 0.4%
Spain 59 1.6%
Sri Lanka 2 0.1%
Sweden 73 2.0%
Switzerland 56 1.5%
Taiwan 11 0.3%
Thailand 4 0.1%
Trinidad and Tobago 1 0.0%
Tunisia 1 0.0%
Turkey 12 0.3%
Ukraine 22 0.6%
United Kingdom 293 8.1%
United States 1189 32.7%
Uruguay 4 0.1%
Vietnam 3 0.1%
Invalid answer 7 0.2%
Base 3631 / 3868


As one can easily see, slightly less than third of Git users (32.7%) are in the USA (those who answered this survey, and this question). Next of countries is Germany with around 11.0% responses. Third is United Kingdom of Great Britain (including England, Scotland, Wales and Northern Ireland) with 8.1%.

The names of the countries were normalized using Locale::Country Perl module version 2.07 (with the fix that Serbia and Montenegro split into Republic of Serbia and Montenegro on 5 June 2006).

Top 12 Countries:

Country Count Perc.
United States 1189 32.7%
Germany 400 11.0%
United Kingdom 293 8.1%
Canada 158 4.4%
France 157 4.3%
Australia 121 3.3%
Netherlands 76 2.1%
Russian Federation 75 2.1%
Sweden 73 2.0%
Poland 68 1.9%
Italy 65 1.8%
Norway 63 1.7%

You can also take a look at Git Activity Map at Ohloh, where you can see on (large) Google Map locations of selected people who have Git in a stack, or locations of Git contributors (those with known location).

It is a bit pity that this survey did not include question "Does git.git repository include code produced by you?" (or equivalent), so we would be able to see where the developers are.


Continent Count Perc.
Africa 19 0.5%
Asia 201 5.5%
Europe 1769 48.7%
North America 1371 37.8%
South America 98 2.7%
Oceania 161 4.4%
Unknown 12 0.3%

In the table above "Oceania" includes (among others) Australia and New Zealand. As you can see most responders are from Europe (49%, slightly less than half), followed by North America (38% responders).

The conversion from country name to continent was done using Locale::Object::Country Perl module from CPAN, which in turn uses data from http://www.worldatlas.com/cntycont.htm


02. How old are you (in years)?

(tabularized free-form single line)

Histogram of age of responders



Years Count Perc.
< 18 59 1.6%
18-21 339 9.4%
22-25 862 23.8%
26-30 1169 32.3%
31-40 962 26.6%
41-50 168 4.6%
51-75 45 1.2%
76+ 6 0.2%
Not a number 5 0.1%
Base 3615 / 3868


Discounting joke responses (or errors in parsing), youngest user who answered this question is 12 years old, oldest is 90 (next to oldest is 68). That is quite a span.

Most Git users (around one third, 32.3%) fall in the 26-30 range. The age of 27 got most responses (in 2007 it was 25, as it was in 2008).

Getting started with Git

03. Have you found Git easy to learn?

(single choice)

Answer Count Perc.
Very easy 155 4.3%
Easy 750 20.6%
Reasonably easy 1984 54.6%
Hard 675 18.6%
Very hard 71 2.0%
Base 3635 / 3868

Nice Gaussian curve. Most users find it reasonably easy to learn, slightly biased towards easy.


04. Have you found Git easy to use?

(single choice)

Answer Count Perc.
Very easy 356 9.8%
Easy 1348 36.9%
Reasonably easy 1606 44.0%
Hard 301 8.2%
Very hard 40 1.1%
Base 3651 / 3868

Most users find it reasonably easy to easy to use Git.

When analyzing this data (and the data for the question before) you should take into account that somebody considering or finding Git too hard to learn wouldn't be probably Git user, and thus wouldn't fill this survey. So because it is *Git User's* Survey we should consider that results can be skewed towards lower value (easier).

What's interesting is comparing (percentage) results for questions 3. and 4.; how hard is git to learn versus how hard is to use. It seems like Git is reasonably easy to learn, and reasonably easy to easy to use. So it looks like Git just have somewhat steep learning curve, and the difficulty to learn pays in being more powerful to use.


05. Which Git version(s) are you using?

(multiple choice, with other)

Version Count Perc.
pre 1.3 9 0.2%
1.3.x 14 0.4%
1.4.x 46 1.3%
1.5.x 698 19.0%
1.6.x 3271 89.2%
minor (maintenance) release 1.x.y.z 978 26.7%
'master' branch of official git repository 220 6.0%
'next' branch of official git repository 43 1.2%
other, please specify 68 1.9%
Base 3666 / 3868

Description:
One can find git version by using "`git --version`" or "`git version`".

"Minor release" is additional specification, so if one for example use git version 1.6.3.3, one should check both "1.6.x" and "minor release".


Analysis:
As you can see from above results great majority (83%) run latest 1.6.x series of git (note: because it is multiple-choice question it means 'at least on one machine'). Only a few use 1.3.x or pre 1.3 versions somewhere.

Only a bit more than one fourth (26.7%) of responders use (somewhere) maintenance releases. That, or the question was,'t formulated clear enough.


06. Rate your own proficiency with Git:

(single choice)

Proficiency Count Perc.
1. novice 156 4.2%
2. casual, needs advice 675 18.3%
3. everyday use 1418 38.5%
4. can offer advice 1204 32.7%
5. know it very well 228 6.2%
Base 3681 / 3868


Description:
One can think of it as 1-5 numerical grade of your proficiency in Git.


Analysis:
As you can see most responders know Git enough for everyday use, or can even offer some Git advice. If we treat possible answers as a proficiency grade, the average proficiency is around 3.2.

Either Git users don't stay novices long, or survey announcement(s) didn't reach novice users.

This data could be useful later to be able to check how it differs git usage for novices and for gurus (what commands they run, what features they use at different levels of proficiency).


How you use Git

07. I use Git for (check all that apply):

(multiple choice, with other)

Note that above choices are neither orthogonal nor exclusive. One might want to check multiple answers even for a single repository.

Answer Count Perc.
work projects 2908 78.9%
unpaid projects 2887 78.4%
proprietary projects 1332 36.2%
OSS development 2422 65.7%
private (unpublished) code 2834 76.9%
code (programming) 3173 86.1%
personal data 1156 31.4%
documents 1145 31.1%
static website 1037 28.1%
web app 1527 41.4%
sharing data or sync 777 21.1%
backup 893 24.2%
backend for wiki, blog, or other web app 318 8.6%
managing configuration files 1202 32.6%
frontend to other SCM (e.g. git-svn) 1145 31.1%
other (please specify) 97 2.6%
Base 3684 / 3868


Description:
Note that above choices are neither orthogonal nor exclusive. You might want to check multiple answers even for a single repository.


08. How do/did you obtain Git (install and/or upgrade)?

(multiple choice, with other)

Note that this question is multiple choices question because one can install Git in different ways on different machines or on different operating systems.

Answer Count Perc.
binary package 2624 71.5%
source package or script 853 23.3%
source tarball 741 20.2%
pull from (main) repository 632 17.2%
preinstalled / sysadmin job 236 6.4%
other - please specify 134 3.7%
Base 3668 / 3868


Description:
Explanation: "binary package" covers pre-compiled binary (e.g. from rpm or deb binary packages); "source package" covers things like deb-src and SRPMS / *.src.rpm; "source script" is meant to cover installation in source-based distributions, like 'emerge' in Gentoo.

Automatic update (apt, yum, etc.) in most cases means binary package install; unless one uses source-based distribution like Gentoo, CRUX, or SourceMage, where automatic update means using source package (or source script).

The option named "preinstalled / sysadmin job" means that either you didn't need to install git because it was preinstalled (and you didn't upgrade); or that you have to ask system administrator to have git installed or upgraded.

Note that this question is multiple choices question because one can install Git in different ways on different machines or on different operating systems.

Analysis:
Most people (71.5%) use ready binary packages, which was kind of expected; that is the easiest way.


09. On which operating system(s) do you use Git?

(multiple choice, with other)

Operating System Count Perc.
Linux 3223 87.5%
MacOS X (Darwin) 1547 42.0%
MS Windows/msysGit (MINGW) 826 22.4%
MS Windows/Cygwin 367 10.0%
FreeBSD, OpenBSD, NetBSD, etc. 271 7.4%
OpenSolaris 120 3.3%
other Unix 77 2.1%
MS Windows (any) 1193 32.4%
Other, please specify 45 1.2%
Base 3682 / 3868


Description:
On Unices you can get the name of operating system by running "`uname`".

Analysis:
Most common used operating system is Linux, next is MacOS X, and then MS Windows (on MS Window dominates msysGit version). This is quite understandable, as Git was created on Linux and for Linux, and it works best there.

The "other" answer include Solaris, AIX, HP-UX (other Unix), GNU/Linux (Linux), Debian, NixOS (Linux distributions), none (?); iPod, OpenVMS, QNX, Hurd and "my toaster" (?). And some commentaries and clarifications.


10. What do you use to edit contents under version control with Git?

What kind of editor, IDE or RAD you use working with Git?

(multiple choice, with other)

Answer Count Perc.
simple text editor 942 25.6%
programmers editor 3221 87.6%
IDE or RAD 1208 32.8%
WYSIWYG tool 205 5.6%
other kind 108 2.9%
Base 3678 / 3868


Description:

  • "simple text editor" option includes editors such as pico, nano, joe, Notepad,
  • "programmets editor" option includes editors such as Emacs/XEmacs, Vim, TextMate, SciTE (syntax highlighting, autoindentation, integration with other programmers tools, etc.)
  • "IDE (Integrated Development Environment) and RAD (Rapid Application Development)" option includes tools such as Eclipse, NetBeans IDE, IntelliJ IDE, MS Visual Studio, KDevelop, Anjuta, Xcode, Code::Blocks but also tools such as Quanta+, BlueFish or Screem (for editing HTML, CSS, PHP etc.), and Kile or LEd for LaTeX.
  • "WYSIWYG tools" option includes word processors such as MS Office or OpenOffice.org, but also tools such as Adobe Acrobat (for PDF) or GIMP (for images), or WYSIWYG DTP tools such as QuarkXPress, PageMaker or Scribus, or WYSIWYG HTML editors such as FrontPage, Dreamweaver or KompoZer.


Analysis:
Most popular kind of tool is programmer's editor with very strong 88% lead. Next in turn are IDE or RAD with 33%, followed by simple text editor, with 26%. The WYSIWYG tools are last, with very small 6% of replies; also people who use WYSIWYG tools also use other kind of tools to edit (presumably to edit commit message at least).

From browsing through some of "other tool" responses it seem like there should be included 'web interface' among possible tools (written as: wiki frontend, GitHub editor, <textarea>). Other responses include Xournal (note taking application for graphic tablet, using stylus), Tinderbox (also note taking application), Git GUI tool: GitX (?), custom git-aware CMS (probably also 'web interface'), scripts and oneliners, command line and 'On occasion, Unix text manipulation tools'. Also there is "audio editors" answer (which probably should fall under "WYSIWYG tool)...

Many answers in 'other tool' falls in one of ready categories; perhaps they are clarification of answer?


11. What Git interfaces, implementations, frontends and tools do you use?

(multiple choice, with other)

Answer Count Perc.
git (core) commandline 3557 97.3%
JGit (Java implementation) 164 4.5%
library / language binding 134 3.7%
Cogito (DEPRECATED) 13 0.4%
Easy Git 28 0.8%
Pyrite 7 0.2%
StGIT 61 1.7%
Guilt 15 0.4%
TopGit 38 1.0%
pg aka Patchy Git (DEPRECATED) 2 0.1%
gitk 1673 45.8%
git gui 742 20.3%
QGit 231 6.3%
GitView 22 0.6%
Giggle 156 4.3%
GitNub 152 4.2%
GitX 685 18.7%
git-cola 58 1.6%
tig 209 5.7%
TortoiseGit 201 5.5%
Git Extensions 79 2.2%
git-cheetah 7 0.2%
git-instaweb 101 2.8%
git-sh 54 1.5%
Gitosis (as admin) 398 10.9%
repo (to manage multiple repositories) 65 1.8%
editor/IDE VC integration 417 11.4%
filemanager / shell extension (any) 98 2.7%
graphical history viewer/browser (any) 575 15.7%
graphical commit tool (any) 223 6.1%
graphical diff tool 594 16.3%
graphical merge tool 541 14.8%
graphical blame or pickaxe tool 84 2.3%
my own scripts (for daily use) 318 8.7%
my own scripts (for special tasks) 375 10.3%
Other (please specify) 284 7.8%
Base 3655 / 3868


Description:
Here "graphics diff tool" means tools such as Kompare, and graphical merge tool means tools such as Meld and !KDiff3. Those answers include graphical merge and diff tools used by programmers editors and IDEs.

"graphical history browser (any)" covers tools such as gitk, QGit, Giggle, tig etc., but also built-in git commands such as "`git log --graph`" and "`git show-branch`". If you use one of mentioned tools as history browser, mark both a tool and "graphical history browser (any)"; if you use some graphical history viewer not listed here, please both mark this answer and specify it in the "other tool" answer.

Similarly for other answers marked "(any)".


Analysis:
Currently the above table is only roughly divided into categories and subcategories.


12. What tool (or kind of tool) would you like to have Git support in?

For example IDE, RAD, editors, continuous integration, software hosting, bugtracker, merge tool...; this includes language bindings and Git (re)implementations

(free-form essay)

1308 / 3868 non-empty responses


13. Which git hosting site(s) do you use for your project(s)?

Please check only hosting sites where you publish/push to

(multiple choice, with other)

Hosting site Count Perc.
repo.or.cz 236 6.9%
GitHub 2110 61.9%
Gitorious 345 10.1%
Savannah 46 1.4%
SourceForge 138 4.1%
Assembla 44 1.3%
Unfuddle 222 6.5%
kernel.org 58 1.7%
freedesktop.org 56 1.6%
Alioth 78 2.3%
Fedora Hosted 52 1.5%
git hosting site for related projects 102 3.0%
generic site without git support 127 3.7%
self hosted 1929 56.6%
Other (please specify) 187 5.5%
Base 3407 / 3868


Note that replies might be affected by the fact that announcement about this survey was shown at some git hosting sites, but not at other (additionally users of some git hosting sites may skip welcome page more often than for other hosting site; not all hosting sites have blog or a news / announcements section).

Note also that there probably are other git hosting sites that were not present in the ready list of answers, but are hiding in the "other (please specify)", like for example Codebase.

The leader here is (like in previous years) GitHub (62%); only self hosted has similar amount of replies (57%).


14. How do you fetch/get changes from upstream repositories?

(multiple choice, with other)

Answer Count Perc.
git protocol 2818 78.5%
ssh 2562 71.4%
http 1164 32.4%
rsync (DEPRECATED) 19 0.5%
filesystem 868 24.2%
via git-bundle 66 1.8%
foreign SCM (e.g. git-svn) 799 22.3%
Other, please specify 48 1.3%
Base 3588 / 3868


Description:
This question asks about how do you get changes (updates) from projects you follow into your local repository. It is not about how do you get latest version of Git.

Fetching (or rather cloning) via bundle could mean that project publishes ready for download bundles to reduce traffic and load on server (HTTP download [of bundle] can be resumed, git-clone currently cannot; one can also distribute bundle using P2P).


15. How do you publish/propagate your changes?

(multiple choice, with other)

Answer Count Perc.
push 3285 92.7%
pull request (+ any form of announcement / notification) 1003 28.3%
format-patch + email 789 22.3%
format-patch + other (e.g. reviewboard, issue tracker or forum) 342 9.7%
git bundle 78 2.2%
git-svn (to Subversion repository) 879 24.8%
git-p4 (to Perforce repository) 34 1.0%
foreign SCM interface (other than mentioned above) 71 2.0%
other - please specify 94 2.7%
Base 3543 / 3868

Description:
Publishing via bundle could mean sending bundle via email, or posting it on review board (or forum).


16. How often do you use the following forms of git commands or extra git tools?

(matrix)

Answer never rarely sometimes often Avg. / Count
git add -i / -p 1259 37.4% 586 17.4% 669 19.9% 849 25.2% 2.3 / 3363
git add -u / -A 1744 51.9% 565 16.8% 453 13.5% 588 17.5% 2.0 / 3350
git am 2128 63.3% 522 15.5% 402 12.0% 273 8.1% 1.6 / 3325
git am -i 2567 76.3% 382 11.4% 188 5.6% 162 4.8% 1.4 / 3299
git apply 1908 56.7% 717 21.3% 441 13.1% 215 6.4% 1.7 / 3281
git apply --whitespace=fix 2503 74.4% 397 11.8% 201 6.0% 146 4.3% 1.4 / 3247
git archive 2246 66.8% 460 13.7% 346 10.3% 170 5.1% 1.5 / 3222
git bisect 1704 50.7% 763 22.7% 541 16.1% 191 5.7% 1.8 / 3199
git bisect run <cmd> 2352 69.9% 474 14.1% 249 7.4% 105 3.1% 1.4 / 3180
git annotate 2174 64.6% 509 15.1% 318 9.5% 155 4.6% 1.5 / 3156
git gui blame 2477 73.7% 340 10.1% 220 6.5% 99 2.9% 1.3 / 3136
git blame 1473 43.8% 724 21.5% 682 20.3% 240 7.1% 1.9 / 3119
git blame -L <start>,<end> etc. 2539 75.5% 342 10.2% 139 4.1% 83 2.5% 1.3 / 3103
git bundle 2680 79.7% 248 7.4% 100 3.0% 60 1.8% 1.2 / 3088
git cherry 2302 68.5% 417 12.4% 251 7.5% 107 3.2% 1.4 / 3077
git cherry-pick 1455 43.3% 604 18.0% 649 19.3% 364 10.8% 2.0 / 3072
git cherry-pick -n / --no-commit 2182 64.9% 476 14.2% 258 7.7% 150 4.5% 1.5 / 3066
git citool 2601 77.3% 186 5.5% 111 3.3% 159 4.7% 1.3 / 3057
git clean 1483 44.1% 602 17.9% 417 12.4% 547 16.3% 2.0 / 3049
git add + git commit 278 8.3% 183 5.4% 393 11.7% 2189 65.1% 3.5 / 3043
git commit -a 431 12.8% 363 10.8% 535 15.9% 1711 50.9% 3.2 / 3040
git commit <file>... 999 29.7% 468 13.9% 529 15.7% 1039 30.9% 2.5 / 3035
git commit -i <file>... 1849 55.0% 508 15.1% 338 10.1% 337 10.0% 1.7 / 3032
git commit --amend 1294 38.5% 470 14.0% 620 18.4% 646 19.2% 2.2 / 3030
git cvsexportcommit 2851 84.8% 103 3.1% 40 1.2% 35 1.0% 1.1 / 3029
git cvsserver 2819 83.8% 122 3.6% 54 1.6% 30 0.9% 1.1 / 3025
git daemon (pushing enabled) 2522 75.0% 300 8.9% 112 3.3% 89 2.6% 1.3 / 3023
git difftool 2253 67.0% 377 11.2% 245 7.3% 146 4.3% 1.4 / 3021
git ... --dirstat 2348 69.8% 339 10.1% 199 5.9% 134 4.0% 1.4 / 3020
git fetch [<options>] 1156 34.4% 656 19.5% 604 18.0% 602 17.9% 2.2 / 3018
git filter-branch 2215 65.9% 560 16.7% 176 5.2% 64 1.9% 1.4 / 3015
git format-patch 1778 52.9% 521 15.5% 421 12.5% 292 8.7% 1.7 / 3012
git grep 1949 58.0% 467 13.9% 254 7.6% 339 10.1% 1.7 / 3009
git imap-send 2748 81.7% 142 4.2% 70 2.1% 47 1.4% 1.1 / 3007
git instaweb 2375 70.6% 332 9.9% 183 5.4% 116 3.4% 1.3 / 3006
git log --grep/--author/... 1408 41.9% 619 18.4% 569 16.9% 407 12.1% 2.0 / 3003
git log -S<string> (pickaxe search) 1987 59.1% 515 15.3% 326 9.7% 172 5.1% 1.6 / 3000
git log --graph 1692 50.3% 662 19.7% 361 10.7% 278 8.3% 1.7 / 2993
git merge 809 24.1% 581 17.3% 820 24.4% 781 23.2% 2.5 / 2991
git merge with strategy 2151 64.0% 517 15.4% 207 6.2% 115 3.4% 1.4 / 2990
git merge --squash 2008 59.7% 490 14.6% 278 8.3% 208 6.2% 1.6 / 2984
git mergetool 1839 54.7% 400 11.9% 304 9.0% 431 12.8% 1.8 / 2974
git pull (no remote) 732 21.8% 510 15.2% 575 17.1% 1147 34.1% 2.7 / 2964
git pull --rebase [<options>] 1251 37.2% 603 17.9% 504 15.0% 580 17.2% 2.1 / 2938
git pull <remote> 486 14.5% 550 16.4% 738 21.9% 1090 32.4% 2.8 / 2864
git pull <URL> <ref> 932 27.7% 635 18.9% 439 13.1% 697 20.7% 2.3 / 2703
git push 110 3.3% 158 4.7% 359 10.7% 1563 46.5% 3.5 / 2190
Base 3363 / 3868


Description:
This question (and its continuation below) is entirely optional.


17. How often do you use the following forms of git commands or extra git tools? (continued)

(matrix)

Answer never rarely sometimes often Avg. / Count
git relink 2753 87.0% 152 4.8% 138 4.4% 123 3.9% 1.3 / 3166
git rebase 742 23.4% 704 22.2% 791 25.0% 869 27.4% 2.6 / 3106
git rebase -i 1331 42.0% 453 14.3% 552 17.4% 717 22.6% 2.2 / 3053
git reflog or git log -g 1992 62.9% 486 15.4% 383 12.1% 148 4.7% 1.6 / 3009
git remote 1027 32.4% 617 19.5% 885 28.0% 443 14.0% 2.3 / 2972
git remote update 1905 60.2% 451 14.2% 330 10.4% 248 7.8% 1.6 / 2934
git request-pull 2482 78.4% 243 7.7% 135 4.3% 48 1.5% 1.2 / 2908
git revert 972 30.7% 975 30.8% 773 24.4% 178 5.6% 2.1 / 2898
git send-email 2382 75.2% 244 7.7% 150 4.7% 109 3.4% 1.3 / 2885
git show-branch 2171 68.6% 386 12.2% 229 7.2% 94 3.0% 1.4 / 2880
git shortlog 1996 63.0% 514 16.2% 260 8.2% 104 3.3% 1.5 / 2874
git shortlog -s 2277 71.9% 316 10.0% 170 5.4% 110 3.5% 1.3 / 2873
git stash 865 27.3% 430 13.6% 788 24.9% 789 24.9% 2.5 / 2872
git stash --keep-index 2328 73.5% 303 9.6% 157 5.0% 82 2.6% 1.3 / 2870
git submodule 1941 61.3% 467 14.8% 289 9.1% 172 5.4% 1.5 / 2869
git subtree 2590 81.8% 170 5.4% 61 1.9% 45 1.4% 1.1 / 2866
git svn 1470 46.4% 473 14.9% 414 13.1% 507 16.0% 2.0 / 2864
git whatchanged 2261 71.4% 338 10.7% 161 5.1% 98 3.1% 1.3 / 2858
git gui 1822 57.5% 408 12.9% 256 8.1% 335 10.6% 1.7 / 2821
gitk 995 31.4% 444 14.0% 489 15.4% 687 21.7% 2.3 / 2615
Base 3166 / 3868


Description:
Explanation: "Rarely" means that you use mentioned form of command either rarely, or you have used it only a few times.

Questions 16 and 17 (its continuation) are purely optional (as are the rest of questions in survey). If you don't feel like filling this questions, please skip them.

Note: git-subtree is managed out of tree, as a separate project (not in git.git repository, not even in contrib/ area). Originally git-subtree was submitted for inclusion, and later was considered for 'contrib/', but it was decided that it would be better if it mature out-of-tree, before resubmitting.


18. Which of the following features have you used?

(multiple choice, with other)

Feature Count Perc.
git bundle (off-line transport) 255 8.4%
eol conversion (crlf) 474 15.6%
gitattributes 298 9.8%
mergetool and/or difftool, or custom diff/merge driver 1024 33.8%
submodules (subprojects) 1003 33.1%
subtree merge (optionally git-subtree) 152 5.0%
separate worktree / core.worktree 116 3.8%
multiple worktrees (git-new-worktree) 119 3.9%
alternates mechanism (sharing object database) 154 5.1%
stash (optionally "git stash --keep-index") 2141 70.7%
shallow clone (e.g. "git clone --depth=<n>") 370 12.2%
detaching HEAD (e.g. "git checkout HEAD^0") 696 23.0%
interactive rebase (small scale history editing) 1420 46.9%
interactive commit / per-hunk comitting / partial commit 1369 45.2%
commit message templates 178 5.9%
git-filter-branch or equivalent (large history rewriting) 442 14.6%
bisect (optionally "git bisect run <script>") 1159 38.3%
committing with dirty tree (keeping some changes uncommitted) 1658 54.7%
non-default hooks (from contrib/hooks/ or other) 520 17.2%
shell completion of commands 1756 58.0%
git-aware shell prompt 1154 38.1%
git aliases, shell aliases for git, or own git scripts 1386 45.7%
Other, please specify 23 0.8%
Base 3030 / 3868


19. What features would you like implemented in Git? What features are you missing?

(free-form essay)

1097 / 3868 non-empty responses

Description:

EXAMPLES: partial / subtree checkout, commit annotations aka git-notes, refs/replace/* mechanism, "smart" HTTP protocol (git via HTTP), resumable clone/fetch, lazy clone (on demand downloading of objects), wholesame directory rename detection, syntax highlighting and/or side-by-side diffs in gitweb, graphical merge tool integrated with git-gui, etc.

Analysis:

Below there is summary of around first 50% of responses (proposed features), divided into rough categories.

  • performance
    • better support for big files (large media)
    • speed up "resolving deltas" step on large repositories
    • better performance on very large (multiple gigabyte) repositories
    • git-status faster on large binary files
    • "shallow history" binaries (e.g. for large files) / "selective shallow history"
    • unobtrusive incremental repacking (better algorithm)


  • generic git improvements and new features
    • support for tracking empty directories
    • full ignoring of case, including .gitignore and git-status
    • "partial submodules", mount part of repository in some other repo
    • better shallow clones support
    • better line ending handling
    • filename encoding (in repository vs in filesystem)
    • standarize on UTF-8 for filenames in core
    • standarize on UTF-8 for commit messages, get encoding from locale
    • better support for sharing objects
    • union checkouts (some files from one branch, some from other) (?)
    • git "overlays", i.e. mixing several git repos in one working directory, a bit like unionfs for git working area
    • advisory locking / "this file is being edited"
    • locking / git-lock
    • optional/pluggable user and file edit tracking (advisiory locking?)
    • wholesame directory rename detection / subtree rename detection
    • tracking of multiple worktrees without symlinks
    • warn when commit or merge leave file empty
    • interactive prompts (for new users)
    • rename tracking via annotations
    • repo-specific (local) version number scheme, similar to Mercurial
    • http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less
    • obsoleting of branches (keep them, use only on demand)
    • ACL
    • grouping files in staging area, comitting by such group (splitting commit) to split changes in working area into two commits
    • local tags
    • comments on branches / descriptions of branches
    • optional metadata storage (permissions, timestamps, EA, ownership)
    • git sequencer merged


  • safety
    • save unstaged data somewhere for "git reset --hard" to be recoverable
    • make "git stash apply" to not lose index by default
    • track published revisions to warn against rewriting published history (warn before/when rewriting published history)
    • teach reset/checkout to warn about rebase in progress (safety check to warn when/forbid comitting when inside rebase/am)
    • easy way to tell which commits are in local repository only
    • branch.<name>.rebase = true, but rebase only up until the last merge
    • more safety, e.g. for 'git checkout *'
    • robustness, fewer weird errors
    • fix bug: files wrongly deleted when directory replaced by symlink


  • generic command line improvemenents and new commands
    • undo buffer for reverting a file (single-file stash?)
    • svn/bzr/hg/darcs-like revert (revert-edits)
    • better undo/abort/continue
    • better oops/undo actions, easier undo features (commit, merge, etc.)
    • 'git undo' (universal undo)
    • git command history, with ability to undo commands (multi-level?) via "git undo"
    • git merge --abort
    • '-n' like option for each command, which describes what would happen
    • preview to what git-revert would do
    • better error messages
    • improve error reporting and frontend usability
    • localization of command-line messages
    • units of all numbers in git commands output
    • alternate, easier to use porcelain
    • zsh command line completion for aliases
    • more informative error messages, e.g. for "git push master origin" instead of "git push origin master" (newbie friendly)
    • hooks / deep integration with ticketing system / issue tracker, like requiring ticket number in commit (?)
    • more hooks
    • clearer error messages (less references to git implementation details)
    • a bit more coherence in terms of interface would be much appreciated
    • better CRLF support, in particular files dirty due to CRLF mismatch
    • git imap-retrieve <msg-id> | git am -3
    • git-kill command (???)
    • built-in tutorial mode
    • aliases for pre-defined --pretty=, like --oneline
    • environmental variable for templates location
    • support multiple template directories in init command (?)
    • git-subtree should be a part of git-core
    • tool to manage git repositories (???: repo, gitosis, gitolite)
    • git cp
    • git-media http://gist.github.com/79247
    • built-in Quilt-like patch management interface (like StGIT or Guilt)
    • "git unstage" (built-in alias for "git reset HEAD")
    • git stage / git unstage
    • setting default options (parameters) in config / aliasing git commands


  • improvements of transport (git clone, fetch and push)
    • resumable clone/fetch (remote operations)
    • resumable push
    • lazy clone
    • view log without cloning repo (to view changes in remotes)
    • remote operations? git diff/log REMOTE:COMMITISH..REMOTE:COMMITISH
    • fetching reflog from other repository (?)
    • recursively clone submodules (option)
    • git push --create
    • easy way to clone single branch
    • easy way to do shallow clone of a single branch
    • pushing to shallow clones / better shallow clone support
    • shallow cloning/fetch starting at COMMITISH rather than at DEPTH
    • partial clone / clone a subdirectory
    • git push --track / better support for centralized workflows
    • push over ftp
    • SASL authentication on pushes over git://
      authentication and encryption for git protocol
    • ask for password only once (http(s), ssh, ...)
    • add some curl options to the command line, so .netrc is not required
    • better HTTP/(WebDAV) support with custom ACL
    • mod_git for Apache
    • push to non-bare with automatic checkout (sample hook?)
    • built-in gitjour/bananajour
    • git clone --peer (for multi-peer mothership/satelite setup)
    • distributed distribution protocol, a la GitTorrent
    • BitTorrent-like transfers (GitTorrent) for slow/long-term transport
    • show network progress if verbose (curl has progres option)
    • git-update-server-info should be somehow run automatically
    • simple publishing on restricted servers (no git), e.g. push via ftp
    • git sync <remote>
    • the universal "git update"
    • git pushall and pullall
    • (optional) autostash/unstash around git-pull, when pulling into dirty tree


  • interacting with remotes and remote-tracking branches
    see also subsection above
    • remote branches listed with local branches ('git branch -v -v'?)
    • easier way to see which branches are tracking which ones
    • clearer/more intuitive way to clean out remote tracking branches that no longer exist on the remote
    • clearer/more intuitive way to remove remote branches
    • git remote prune --all
    • better remote branch management (?)
    • git_remote_branch ruby gem functionality
    • synchronization of branches withour remote-tracking branches, like in hg
    • a way to refer "last used" remote, or default to last used remote (?)
    • view log without cloning repo (to view changes in remotes)
    • replicated (transferable) per-branch meta-information
    • a command which would show which branches are divergent so that they would create conflict during merge (and support in gitk/git-gui for this)


  • improvements to diff
    • "show all changes to function X"
    • diff between two different working trees
    • 'git diff -I' (similar to 'cvs diff -I'), i.e. "-I REGEXP:: Ignore changes that just insert or delete lines that match REGEXP."
    • diffs with sub-line granularity
    • diff by author (?)
    • difftool with support for tools that can diff entire tree of files, instead of diff one file at a time (same with mergetool)


  • improvements to merge
    • A sensible way of delaying conflicts with non-text files e.g.keeping both files around and renaming them for later merging in OpenOffice etc.
    • automatically run merge tool on merge conflict
    • option/command to undo auto-merge to do merge manually
    • better whitespace handling on merges / rebases
    • http://thomas.apestaart.org/log/?p=898 (about git merge conflict)


  • improvements to other git commands
    • environmental variables in config, expanding ~ and ~user in paths
    • git status --format=...
    • git archive --format=tgz
    • git merge --ff=only (--ff flavors) / git pull --ff=only
    • mass update/rebase of a number of local branches (is it possible?)
    • easier conflict resolution (how?)
    • "longest common changed path" option for log formats
    • 'git log --follow' to follow through evil merges with renames etc.
    • git commit --amend HEAD~2
    • "git commit <file>" for untracked file
    • git commit --interactive <files>
    • git checkout -i, git stash -i
    • git log foo/bar.c:123-150, limiting results to changing given lines
    • multiple indices/staging areas ("git add --to-index <index> <file>")
    • 'git mergetool -t emerge' that works with emacsclient / gnuclient
    • better intergation with KDiff3
    • more grep-specific arguments in git-grep
    • git merge --abort
    • git cherry-pick <revision> -- <file>
    • "git stash apply 1" or "git stash apply <label>", not stash@{1}
    • rebase -i -p with commit reordering (e.g. via git-sequencer)
    • head tips in log --graph
    • 'split' instruction for interactive rebase
    • template for cover letter / input cover letter for git-format-patch
    • make git fetch && git merge be the same as git pull


  • additional tools
    • interactive blame tool (where did this line come from)
    • graphical interactive rebasing
    • visual map of reflog
    • graphical tool for cherry-picking and squashing


  • gitweb, web interfaces
    • categories support in gitweb, with collapsible groups
    • syntax highlighting in gitweb
    • side-by-side diffs in gitweb
    • color-words diff in gitweb
    • graphical history view in gitweb
    • gitweb should give more graphics and stats (timeline with commit count per branch, commit graphs,...)
    • (easily) customizable diff formats in gitweb
    • (easy) comparing arbitrary commits in gitweb
      easy to use/find arbitrary diffs in gitweb
    • nicer URLs in gitweb (like in cgit)
    • RDFa in gitweb
    • commit annotations (committags) in gitweb (probably)
    • admin features in gitweb
    • more advanced search options in gitweb (i.e. expose options such as --since=, --util=)
    • ajax/web 2.0 type web front end
    • git-instaweb should be github-like


  • submodules
    • submodule interface improvements
    • non-pegged submodules (use most recent HEAD/branch, not sha1) (?)
    • better recursive submodule support
    • support foreign SCM source as submodule
    • read-only submodules
    • "partial submodules", mount part of repository in some other repo
    • submodules autoupdated on pull
    • using tags/branches in git-submodule (?)
    • recursively clone submodules (option)
    • GUI for submodules (or support for submodules in git-gui)
    • submodules and switching branches
    • submodules with ability to set up alternates before submodule checkout
    • support for submodules in git-archive
    • an easy way to remove submodules from a project
    • fix "git add path/" vs "git add path" gotcha with submodules
    • forests (a la Mercurial) - perhaps similar to svn:externals or git-ext


  • gitk and git-gui (GUI)
    • better integration of git-gui and gitk
    • revert chunks in git-gui
    • GUI for submodules (or support for submodules in git-gui)
    • GUI for rebase in git-gui
    • GUI for creating repository in git-gui
    • GUI tool to manage set of git repositories (config, access,...)
    • merge gitk and git-gui
    • support for ignoring files (adding to .gitignore) in git-gui
    • graphical merge tool integrated with git-gui
    • tips in gitk / git-gui ("Did you know...")
    • "commands issued" (or "command equivalents") in git-gui / gitk
    • gitk more like GitX graphs (complex graphs)
    • make gitk and git-gui friendlier (?)
    • gitk / git-gui supporting list of ref glob patterns
      (DONE with --glob=<pattern> option to git-rev-list / git-log)
    • autorefresh of refs in gitk and git-gui
    • revert (i.e. delete) single hunk in git-gui ("unstage these lines")
    • syntax highlighting in git-gui
    • font-smoothing in git-gui
    • support for rebasing in git-gui
    • support for undoing local modifications in files in git-gui
    • running diff and merge tool from git-gui
    • better git blame GUI tools
    • support for shallow clones in GUI tools
    • editing commits, etc. in GUI via git-replace/grafts
    • visual map of reflog
    • graphical interactive rebasing


  • documentation
    • git overview manpage, like perl5 and zsh
    • documentation on commit message templates
    • more examples in manpages
    • example workflows in documentation
    • document centralized (no maintainer) workflow
    • better "getting started" documentation for newbies (git-intro)
    • more topic "How do I ..." style docs
    • remove references to since removed git-svnimport command
    • git-ai: ai help with docs
    • concise help output listing medium/advanced features
    • better documentation (manpages) and error messages
    • tutorial visualization tool (rebase vs merge, reset vs revert)


  • interacting with other version control tools
    • uniform interface to foreign SCMs repositories (bidirectional)
    • support foreign SCM source as submodule
    • git svn switch
    • SVN metadata outside git commit (extra files, or notes)
    • http://bugs.debian.org/git-svn
    • git-bzr and git-hg
    • git-svnserver and git-bzrserver
    • conversion from bzr, perforce, etc.
    • git-svn on subsection of history / subset of branches
    • partial SVN branch checkouts (tracking only some of branches)
    • git svn partial checkout
    • lazy "git svn clone"
    • proper support for svn:externals in git-svn
    • git-svn support for svn:eol-style native
    • better default hooks for git-svn, e.g. creating new branch in git would create a new branch in svn (partial svn branch integration)
    • git-svn in C, not in Perl (depending on libsvn C API)
    • more flexible git-svn wrt trunk/tags/branch names, or better examples
    • better git-p4


  • portability
    • git-daemon support in msysGit
    • git-daemon in msysgit
    • easier msysGit upgrading (keep the same options as previous install)
    • better MS Windows suport
    • better encoding support on MS Windows
    • graphical history browser for MS Windows
    • better graphical tool for OSX, with integrated merge tool
    • portable TortoiseGit / Git-Cheetah for USB (PortableApps)


  • bindings
    • libgit / LGPL libgit
    • Git.pm better supported
    • pull/merge support in EGit/JGit
    • write plugins using scripting languages like Perl or Ruby (?)
    • plugin architecture like bzr and hg has
    • python bindings


  • installation
    • make uninstall

What you think of Git

20. Overall, how happy are you with Git?

(single choice)

Answer Count Perc.
unhappy 35 1.0%
not so happy 157 4.4%
happy 842 23.5%
very happy 1841 51.3%
completely ecstatic 711 19.8%
Base 3586 / 3868

There were some complaints during planning stage of this year survey that the answers for this question are not symmetric; nevertheless it is set of answers that was used in previous survey(s), and it would help comparing data with previous surveys to keep the current form.

Most responders are "very happy" with Git, and this answer seems to be a center of responses. One should take into account that if one is unhappy with Git, it is less likely that one would continue using it (unless other circumstances would force using it, like the project one contributes to using Git as DVCS of choice), thus less likely to be Git user and to participate in this Git User's Survey. There can be bias because it is Git survey; it might be different if it was generic survey about (distributed) version control systems.


21. In your opinion, which areas in Git need improvement?

Please state your preference.

(matrix)

Answer don't need a little some much Avg. / Count
user-interface 502 14.6% 976 28.3% 1179 34.2% 791 22.9% 2.7 / 3448
documentation 408 11.8% 1034 30.0% 1347 39.1% 604 17.5% 2.6 / 3393
performance 2348 68.1% 737 21.4% 209 6.1% 56 1.6% 1.4 / 3350
more features 1733 50.3% 1105 32.0% 407 11.8% 69 2.0% 1.6 / 3314
tools (e.g. GUI) 787 22.8% 742 21.5% 953 27.6% 802 23.3% 2.5 / 3284
localization (translation) 2326 67.5% 427 12.4% 241 7.0% 98 2.8% 1.4 / 3092
Base 3448 / 3868

Going by average rating (the number before slash '/' in the last column of the table above), it is documentation (2.60) and user-interface (2.59), and then tools (2.51) that needs improvements. Going by the percantages of respective responses, areas that needs improvement 'much' are tools (24%), UI (22%) and documentation (17%); the same set, different priority. Areas that needs 'some' improvement are documentation (40%), then UI (33%) and tools (30%). Areas that 'don't need' improvements are localization (translations) and performance, both with around 69%, then 'more features' with 51%.

The answer about translations might be not representative, because this survey is in English, and it was announced on English-language sites. So there might be some bias towards using English, and away from using localized version.


Changes in Git (since year ago, or since you started using it)

22. Did you participate in previous Git User's Surveys?

(multiple choice)

Survey resp [%] resp [n] in year
in 2006 10.8% 92 117
in 2007 30.8% 263 683
in 2008 97.1% 828 3236
Base 853 / 3868

Note that opposed to other questions, for this one not answering the question is a legitimate answer, and not skipping it.

"In year" column refers to number of replies (number of responses) in the Git User's Survey for given year.

Percentages are relative to the number of people who answered this question, not to the number of people who answered (participated in) this survey.

Year resp resp in year
/ 3519 / in year
in 2006 2.5% 75.2% 117
in 2007 7.1% 36.8% 683
in 2008 22.8% 24.8% 3236

Without further analysis (and the data that we don't have) we can only assume that 2006 survey (narrowly announced) was answered mainly by hard-core Git users and contributors, which follow Git announcements and participate in surveys. Therefore large number of people who participated in 2006 survey also participated in 2009 survey.

Note that 2008 (previous) and 2009 (this one) surveys were announced in slightly different ways: 2008 was announced on git mailing lists, 2009 was announced on blogs and hosting sites.


23. How do you compare the current version with the version from one year ago?

(single choice)

Answer Count Perc.
better 1486 49.0%
no changes 244 8.0%
worse 11 0.4%
cannot say 1293 42.6%
Base 3034 / 3868

Description:
The version from approximately one year ago is 1.5.6 from 18-06-2008, the last version in 1.5.x series (except maintenance releases from 1.5.6.1 to 1.5.6.6). Major controversial change in 1.6.0 was installing most of the programs outside your $PATH.

Other changes include:

  • stash never expires by default
  • git-branch got -v, --contains and --merged options
  • fast-export / fast-import learned to export and import marks file
  • "git stash save" learned --keep-index option; "git stash" learned "branch" subcommand
  • when you mistype a command name, git can suggest what you might meant to say
  • git add -N / --intent-to-add
  • built in synonym "git stage" for "git add", and --staged for --cached
  • improvements to "git bisect skip" (can take range, more aggresive)
  • "git diff" can use varying mnemonic prefixes, learned "textconv" filter
  • "git log" learned --simplify-merges, --source, --simplify-by-decoration
  • "git send-email" can automatically run "git format-patch"
  • unconfigured git-push issue now a big warning (preparing for the future incompatibile change)
  • you can use @{-1} to refer to the last branch you were on
  • "git diff" learned --inter-hunk-context and can be told to run --patience diff
  • git-difftool can run graphical diff tool

(see individual RelNotes for more details)


Analysis:
Most people (50%) think that Git improved since year ago; very few (10 in 2785) think it is worse... but almost as many 'cannot say' (42%) if it is better than year ago.

If we take 'cannot say' as indication that responder didn't use Git a year ago, and that is the reason they cannot do comparison, it seems that there are many new Git users participating in this survey.


Documentation. Getting help.

24. How useful have you found the following forms of Git documentation?

(matrix)

Answer never used not useful somewhat useful Avg. / Count
Git Wiki 1242 35.9% 150 4.3% 1295 37.4% 777 22.4% 2.5 / 3464
on-line help 443 12.8% 106 3.1% 1398 40.4% 1479 42.7% 3.1 / 3426
help distributed with git 269 7.8% 214 6.2% 1211 35.0% 1664 48.0% 3.3 / 3358
Base 3464 / 3868


Description:

Analysis:
Least used form of documentation is Git Wiki (http://git.or.cz/gitwiki at the point of running this survey, http://git.wiki.kernel.org currently) with 36% responders never using it, but those that use it feel that it is "somewhat" useful to "useful".

Both help distributed with Git (manpages, Git User's Manual, HOWTOs, etc.) and on-line help (including but not limited to Git Community Book, and tutorials and guides on Git homepage) are almost the same useful, with help included in Git felt to be more useful than on-line help (49% vs 43% is "useful", 36% vs 40% only "somewhat" useful).


25. Have you tried to get help regarding Git from other people?

(single choice)

This question, and questions following it were meant to be about getting help from other people , rather than trying to find help by self. From the set of "other (please specify)" answers for "help channel", which include among others many instances of "Google search" or equivalent, it looks like it was not entirely clean.

Answer Count Perc.
Yes 2261 64.7%
No 1236 35.3%
Base 3497 / 3868

As you can see 2/3 responders tried to get help regarding Git from other people.


26. If yes, did you get these problems resolved quickly and to your liking?

(single choice)

Answer Count Perc.
Yes 1458 62.2%
No 133 5.7%
Somewhat 752 32.1%
Base 2343 / 3868

Consistency check: 2082 people answered that they tried to get help about Git from other people, but we have 2157 responses in this question...

It looks like we have good community surrounding Git, if 2/3 Git questions are resolved quickly and accurately, and only 6% couldn't get quick response and one to their liking.


27. What channel(s) did you use to request help?

(multiple choice, with other)

Channel Count Perc.
git mailing list (git@vger.kernel.org) 284 12.2%
"Git for Human Beings" Google Group 55 2.4%
IRC (#git) 716 30.7%
IRC (other git/SCM related, e.g. #github) 227 9.7%
request in blog post or on wiki[1] 188 8.1%
asking git guru/colleague 1360 58.3%
project mailing list, or IRC, or forum 448 19.2%
Twitter or other microblogging platform 287 12.3%
instant messaging (IM) like XMPP/Jabber 442 18.9%
StackOverflow[2] 406 17.4%
other (please specify) 167 7.2%
Base 2333 / 3868

Notes:

  1. ↑ Here I mainly meant asking a question on one's blog, and waiting for response in blog comments, like e.g. http://jjnapiorkowski.vox.com/library/post/migrating-to-git-from-subversion.html , or asking on Git Wiki (as if it was help forum), or on Talk page of some other wiki (no example).
  2. ↑ StackOverflow is a community driven programming-related Q&A site http://stackoverflow.com/questions/tagged/git

Analysis:
Most used 'channel' is to simply ask somebody better versed in Git personally (58%), then is #git channel with usually fast real-time response (31%). Git mailing list has only 12% of replies, below (quite new) forums and project mailing lists (19% - wide category), instant messaging (19%), and quite new StackOverflow (17%), and very similar to microblogging platforms such as Twitter or Identi.ca (also 12%).

"Git for Human Beings" Google Group is rarely used, with only 2% of responses...

As for "other (please specify)" response:

  • There are some responses ("Internet search", "Google", a book) that show that it was not entirely clear that the question was about asking _other people_ for help regarding Git, not searching for help oneself.
  • Some responses (e.g. "colleagues") were variant of provided channel.
  • Some responses were more detailed specification (description) of channel used; examples include "#dri-devel on freenode", "Rick (friend)", "IRC (channel of project using git)", "Rotating my chair and asking", etc.
  • And there were channels that were not included in the list of provided answers (some because channel is rare, some because survey author didn't think of such channel):
    • GitHub mailing list / GitHub Google Group
    • asking a guy who gave a talk about git at a conference
    • messages through GitHub
    • private email
    • direct email with tutorial author
    • msysGit mailing list / msysGit Google Group
    • Server Fault (but Stack Overflow is on list)
    • Specialists at the work office


28. Which communication channel(s) do you use?

Do you read the mailing list, or watch IRC channel?

(multiple choice)

Channel Count Perc.
git@vger.kernel.org (main) 390 41.6%
Git for Human Beings (Google Group) 74 7.9%
msysGit 98 10.4%
#git IRC channel 516 55.0%
#github or #gitorious IRC channel 195 20.8%
#revctrl IRC channel 4 0.4%
Base 938 / 3868

Note that percentage is relative to the (small) number of replies to this question, not relative to the number of all responders.

Among listed channels, most commonly used are #git IRC channel on FreeNode with 54%, and git mailing list (git@vger,kernel.org) with 42%. Third is #github and #gitorious IRC channels together, with 22% or replies to this question.


About this survey. Open forum.

29. How did you hear about this Git User's Survey?

(single choice, with other)

Answer Count Perc.
git mailing list 270 7.7%
git-related mailing list (e.g. msysGit) 39 1.1%
mailing list or forum of some project 201 5.8%
#git IRC channel topic 63 1.8%
announcement on IRC channel 56 1.6%
git homepage 443 12.7%
git wiki 95 2.7%
git hosting site 502 14.4%
software-related web site 140 4.0%
news or social news site (e.g. Digg, Reddit) 95 2.7%
blog (or blog planet) 748 21.5%
other kind of web site 44 1.3%
Twitter or other microblogging platform 350 10.0%
other - please specify 438 12.6%
Base 3484 / 3868


30. What other comments or suggestions do you have that are not covered by the questions above?

(free-form essay)

555 / 3868 non-empty responses

Retrieved from "https://git.wiki.kernel.org/index.php?title=GitSurvey2009&oldid=10672"
Personal tools