GitSurvey2007

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 2007 summary

This is (not finished) summary of Git User's Survey 2007,
ending at state from 28 September 2007 (response ident `46f95167c967b`).

The survey could be found there

• Git User's Survey 2007 at survey.net.nz (closed)
• Graphical results of the survey (same site)

You can get raw data on which this summary is based here:

• Git User's Survey 2007 - Sep 28 - corrected.csv (CSV, 2.39MB)

There were 683 individual responses.
Note that count is not exactly number of people.

Please do not add survey data on this page

---

Table of contents:

---

About you

00. Date of response

Date (extended range)	Count	Perc.
Before	7	1.0%
During	584	85.5%
After	92	13.5%

The ranges 'before', 'during' and 'after' refers to official duration of Git User's Survey 2007, from 20 August 2007 to 10 September 2007. Actually they are corrected to take into account the fact that local date on surveys server (or UTC date) might be different from local date on user computer, so duration of survey is taken as from 2007-08-19 to 2007-09-11.

Most responses are from the start of survey, 20 and 21 August (133 and 103 responses respectively).

01. What country are you in?

Country	Count
Algeria	1
Argentina	3
Australia	25
Austria	9
Belgium	5
Brazil	20
Bulgaria	1
Canada	44
Chile	2
China	4
Colombia	2
Czech Republic	10
Denmark	7
Ecuador	1
Estonia	1
European Union	1
Finland	23
France	36
Germany	64
Greece	3
Hungary	2
India	13
Ireland	2
Israel	6
Italy	14
Japan	4
Jersey	1
Latvia	1
Malaysia	1
Mexico	1
Netherlands	15
New Zealand	5
Norway	14
Philippines	3
Poland	6
Portugal	2
Puerto Rico	1
Romania	1
Russian Federation	6
Samoa	1
Serbia	1
Singapore	2
Slovak Republic	1
Slovenia	2
South Africa	4
Spain	11
Sri Lanka	1
Sweden	14
Switzerland	15
UK / US	1
United Kingdom	40
United States of America	218
Venezuela	1
Vietnam	1
Base	673 / 683
Total (sum)	673

England and Scotland counts as United Kingdom here. UK / US probably means United Kingdom (Great Britain) or United States of America. Table is sorted in alphabetical order.

As one can easily see, slightly less than third of GIT users are in the USA (those who answered this survey).

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

02. What is your preferred non-programming language?

This is multiple answers question, although most people gave only one preferred language.

Language	Count
Afrikaans	1
Bulgarian	1
Castellano	2
Catalan	1
Chinese	2
Czech	10
Danish	6
Dutch	12
English	416
Finnish	16
French	33
Galician	1
German	58
Greek	2
Hebrew	1
Hungarian	3
Italian	9
Japanese	1
LSF (French sign language)	1
Norwegian	4
Polish	5
Portuguese	11
Romanian	1
Russian	13
Serbian	1
Slovenian	2
Spanish	13
Swedish	13
Swiss	1
Ukrainian	1
Vietnamese	1
invalid (computer language)	37
not understood	4
Base	662 / 683
Total (sum)	684

The question itself is not well formulated, as one can see from the number of answers with computer language, and "not understood" answers. I am not native English speaker, but there were suggestions to use "natural language" instead of "non-programming language".

Around two third of git users prefer English language, at least for dealing with computers.

03. How old are you?

Answer	Count
< 18	11
18-21	75
22-25	174
26-30	203
31-40	146
41-50	45
51-75	13
76+	0
Base	667 / 683
Total (sum)	667

Youngest git user who answered this survey is 14 years old, oldest is 74 years old. This is quite a span, I'd say, The age of 25 got most count (51 answers).

04. Which programming languages you are proficient with?

Answer	Count	Perc.
C	582	85.2%
shell	449	65.7%
Perl	244	35.7%
Python	316	46.3%
Tcl/Tk	26	3.8%
Base	642 / 683
Total (sum)	1617

The choices include programming languages used by git. This is multiple choice question (you can be proficient in more than one programming language).

It look like there is only around 3/4 people proficient in Perl as compared to Python; it looks like Python is more popular. C is most popular; shell is more popular than Perl or Python. The fewest people are proficient in Tcl/Tk. I'm sorry, git-gui and gitk guys; it looks like not many developers... around 4% of git users.

You can check what are the contributions of each programming language to Git code at Git Code Analysis at Ohloh. In the table below there is shown state on November 2007 (there are also some lines / files I guess wrongly attributed to Assembly and DOS batch script):

Language	LoC [%]	Perc.
C/C++	51%	85.2%
shell script	28%	65.7%
Perl	13%	35.7%
Tcl	4%	3.8%
Python	2%	46.3%
Emacs Lisp	1%
CSS	<1%

Note that LoC sums to 100% (barring rounding errors), while percent of people proficient in given language doesn't sum to 100% because one can (and usually is) proficient in more than one programming language.

Getting started with GIT

05. How did you hear about GIT?

Answer	Count
LKML	109
LWN (Linux Weekly News)	39
KernelTrap	15
KernelTraffic	1
kernel.org	9
freedesktop.org	5
Linus presentation at Google	48
Slashdot	28
blog	19
community site	12
news site	34
searching Internet	6
other SCM / SCM research	20
Internet	32
IRC	6
Linux kernel uses it	73
some project uses git	47
developer by name	21
friend	39
word of mouth	15
work / coworker	22
initial GIT announcement	12
BitKeeper news	24
don't remember	13
other / uncategorized	44
Base	658 / 683
Total (sum)	693

Footnotes:

This was free-form question, and tabulating answers was quite a work. It is taken as multiple choice question (for example link to Linus presentation at Google found at Slashdot counts as both "Slashdot" and "Linus presentation at Google" answer).

Other / uncategorized includes for example GoogleTalk IM, 3 answers IIRC. There was one answer of 'through the CPAN module' (?).

Note that Linus Torvalds presentation at Google Videos / YouTube got it's own category, and generated quite a bit of git users.

06. Did you find GIT easy to learn?

Answer	Count	Perc.
very easy	38	5.6%
easy	136	19.9%
reasonably	318	46.6%
hard	131	19.2%
very hard	33	4.8%
Base	656 / 683
Total (sum)	656

Nice Gaussian curve. Most users find it reasonably easy to use. On the other hand git is not considered easy...

07. What helped you most in learning to use it?

TO DO (partial)
646 / 683 non-empty responses

Some of the responses:

• documentation (generic)
• man pages
• examples / usage cases in man pages
• everyday GIT, tutorials and user's manual
• wiki examples
• reading mailing list / comp.version-control.git
• people on IRC (not only #git)
• advice from other users / friends / colleagues
• (unofficial) documentation on the web: guides, articles, blogs etc. (Here probably should be a sublist of them, with count)
• a development community and/or its documentation, mailing list e.g. WINE wiki, Source Mage GNU/Linux development community
• Google (Google searches)
• helpful error messages
• source code, reading the parts of git in shell script
• cogito
• using git in a live project / experimenting / trial and error;
  Example answer:That I was able to just delete the entire repository and start over. That all my mistakes stayed local and didn't affect upstream repos.
• working on an established project that had documented processes for using git
• writing code for both plumbing and Porcelain;
  writing documentation / tutorial for project / article
• understanding the internal representation of the repository;<<BR} good / simple design, basic principles; understanding concepts
• experience of working in software industry;
  prior experience with version control systems (GNU Arch, SVN, BK, hg)
• version 1.5
• gitk, qgit; git-gui

One of more interesting:

• We hired a consultant to give us a tutorial

08. What did you find hardest?

TO DO (partial)
596 / 683 non-empty responses

Some of the responses:

• the level of complexity
• user interface: too much / inconsistent commands, too many / cryptic options; distinction between plumbing and porcelain; many ways to do a task; insufficient error messages; 'git <cmd> --help' prints manpage, not concise help summary
• obtuse command messages
• weak porcelain, e.g. git-update-index very central
• git-merge was plumbing
• remote / tracking branches; fetching, pushing and pulling, synchronizing repositories; the fact that push is not an opposite of pull; understanding the difference between committing and publishing
• handling multiple remote repositories
• merge vs rebase, deciding on proper workflow; working with topic branches; modifying a patch series
• merge defaults (which branch gets merged)
• git vs StGIT: slightly different merge conflict handling
• making it work in non-POSIX environments; working with git on case-insensitive and other strange filesystems; compiling on exotic OS, for example AIX; generating man pages
• lack of / bad / outdated / insufficient / badly structured docs; hard to find something in the documentation; git lingo in documentation, documentation for users who know git; using Cogito in some of documentation
• understanding of concepts, thinking in git way; understanding basic concepts and terminology
• distributed SCM concepts, paradigm shift; idea of non-linear history
• index (staging area): understanding, having it visible
• git-diff not showing added files
• commands named differently from equivalents in other SCM; differences from other SCM: git-commit needs '-a' to commit all; changes, strange semantics of git-add, multiple branches in repo; understanding terminology
• importing history from other SCM (bzr, svn)
• reverting changes, amending commit, undoing a commit
• keeping track of where am I, of which version I'm working with finding which branch the change was made on
• learning to use it as maintainer; maintaining "perfect patch series", keeping history clean; rewriting history before 'git rebase -i'
• dealing with merge conflicts; figuring how to undo failed merge and restart it
• learning conventions git expects but didn't document clearly like commit message formatting
• setting up shared repo / shared server; setting up remote repository
• dealing with modified files (dirty tree) when switching branches, merging (pulling) and rebasing
• checking out past revisions (or tagged revisions) with the intention to return to newer revision
• creating independent branch, i.e. branch without ancestry
• exploring the history and previous versions of particular files, which are renamed and/or moved around, especially before '--follow' was added
• some hot-shot people in the community (on the mailing list)
• setting up gitweb
• having to use CLI interface
• no some language documentation

More interesting answers:

• All idiosyncrasies that make (made) sense for Linus' workflow but aren't really orthogonal or predictable.
• Listening to whiners complain about how hard it was to learn
• Thinking outside the narrow box defined by previous SCMs.
• Not having used an SCM before!
• Following the explosive growth of features.
• Having a day job taking most of my time away from git.
• Convincing my boss to use it.

Conclusions:

• some of the things got corrected, like separate remote layout being default for non-bare repositories, using git-add (porcelain) instead of git-update-index (plumbing) in documentation and command messages, promoting git-merge to porcelain, creating git-remote for managing multiple repositories and remote branches, better documentation including creating Git User's Manual.
• some things are hard because of historical reasons, such like naming of commands, or consistency of options, and would be difficult to change.
• doing things "git way", such as making index visible (and requiring 'git commit -a' to commit changes in all files), or rename detection instead of rename tracking, or storing filenames and file contents 'as-is' (without translation) are I think here to stay
• some of things are intrinsically hard, and would stay that way, for example the distributed SCM concept, or non-linear history.

09. When did you start using git? From which version?

TO DO (partial)

Answer (version)	Count
(no version string)	165
0.99x	26
0.x	12
1.0x	31
1.1x	9
1.2x	12
1.3x	22
1.4x	147
1.5x	198
Base	626 / 683
Total (sum)	626

NOTE! This table shows only answers in which there was given Git version explicitly. Some people gave date, some people wrote how long they have used git. Those answers needs also processing; they are not presented here.

It looks like the Git users community is divided into part of users who started using it from beginning, or almost from beginning, and users which started using git post v1.3.0 (post e.g. making separate remotes the default layout of branches).

Other SCMs

10. What other SCMs did/do you use?

This question is not well thought out, as it gathers together (in the free-form which is not easy to tabulate with large number of responses we got) SCMs which one used and no longer uses, SCMs which are used in parallel with git, and SCMs which are used instead of git (which are chosen as main SCM for a project). Nevertheless it shows with which VCS, and its concepts, are users familiar with.

Answer	Count
AccuRev	3
Aegis	1
Bazaar	19
Bazaar-NG	50
BitKeeper	27
CCC	1
CMS (Digital)	1
CMS (VAX)	1
CMS (VMS)	1
CVCS	1
CVS	454
ClearCase	43
CodeMgr	1
Continuus	1
Darcs	78
DesignSync	1
GNU Arch	57
Mercurial	92
Monotone	31
Omniworks	1
OpenCM	1
PRCS	1
PVCS	12
Perforce	50
Quilt	2
RCS	61
SCCS	18
SCM	1
SCSS	1
SVK	19
Serena Version Manager	1
SourceForge	1
Sourcerer's Apprentice	1
StarTeam	4
Subversion	524
Sun NSE	2
Sun TeamWare	4
VCS	1
VMS	1
VSS	26
'cp -a'	1
akpm patch scripts	1
custom in-house tools	1
diff patch	2
notes-on-paper-made-by-hand	1
really horrible stuff	1
scripts for 'shadow trees'	1
tarballs	1
tlib	1
none	9
undisclosed	1
Base	654 / 683
Total (sum)	1615

The above table is in alphabetical order. It was generated from free-form answers, tabulated as multiple choice answer.

Note that this question does not distinguish between SCMs/VCSs which were used prior to Git and used no longer, SCMs which are used beside (in parallel) to Git perhaps interacting with Git, and SCMs which are used instead of Git. Also note that this is Git User's survey, so it those number for example do not represent number of e.g. users of Mercurial as compared to e.g. users of Subversion.

Below there is table of SCM used, sorted by the number of responses. Note that annotations (like "a little CVS") were not weighted here. Only SCMs which has count more that 10 are shown. One person can (and usually did) chose more than one SCM.

In the table below links are to Wikipedia article about specified SCM.

Answer	Count
Subversion	524
CVS	454
Mercurial	92
Darcs	78
RCS	61
GNU Arch	57
Bazaar-NG	50
Perforce	50
ClearCase	43
Monotone	31
BitKeeper	27
VSS (MS Visual SourceSafe)	26
Bazaar	19
SVK	19
SCCS	18
PVCS	12
tla+baz+bzr	129
Base	654 / 683

Footnotes:

As you can see two most popular SCMs are Subversion ('svn') and CVS, with Subversion being a bit more popular. Among distributed SCMs with most count are Mercurial ('hg') and Arch and its descendants ('tla', 'baz', 'bzr'). From proprietary (non-OSS) revision control systems Perforce ('p4'), ClearCase (and ClearCase UCM), BitKeeper ('bk') and Visual SourceSafe (aka. that awful M$ one ;-) got most count.

Note that the count for given version control system does not reflect preferences of git users. One can be forced to use specified SCM.

Compare this to the following table of SCMs popularity, based on the number of people who have given SCM in "stack" on Ohloh. Note that this data might be biased because Ohloh for now supports only CVS, SVN (Subversion) and Git repositories. Data taken on 11-11-2007:

Project	Stacks
Subversion	1568
CVS	223
Git	212
Mercurial	76
Bazaar-NG	43
Darcs	40
SVK	36
Monotone	16

Below there is table of Debian Popularity Contest (popcon) results for SCMs. Table is sorted by the number of installations. Note that popcon only reflects 1/10th to 1/100th or less of total users.

You can also check out popcon graph. Generated graph is for number of installs of git-core, bzr (Bazaar-NG), mercurial and tla (GNU Arch), but you can generate graph for any chosen packages.

SCM	package	installed	vote
CVS	cvs	21778	4813
Subversion	subversion	17391	7275
RCS	rcs	7921	1625
Git	git-core	3243	1533
Mercurial	mercurial	1453	342
Darcs	darcs	1305	322
GNU Arch	tla	1059	167
Bazaar-NG	bzr	1033	258
SVK	svk	655	224
Monotone	monotone	408	91
Aegis	aegis	78	19

Footnotes:

You can also check out (declared) VCS usage for Debian source packages, overview of Version Control System usage to maintain Debian source packages.

SCM	Vcs-*	source packages
Arch	arch	30
Bazaar-NG	bzr	89
CVS	cvs	44
Darcs	darcs	27
Git	git	733
Mercurial	hg	27
Monotone	mtn	0
Subversion	svn	2731

See also question 35: "How does GIT compare to other SCM?".

11. Why did you choose GIT?

(Very similar to question 36. "What do you like about using GIT?")

TO DO (partial)
643 / 683 non-empty responses

What would be most interesting is to have a count for most common answers.

Below there are lists of unique answers, in some arbitrary order.

Generic features which are common to all good distributed open-source SCMs:

• distributed
• offline work (including full history offline)
• atomic commits, tracking whole repository state
• tag support
• GPL / Open Source / free software
• cost: BitKeeper is way too expensive

Features which made responder choose Git:

• reliable, stable, robust
• data integrity; self-checking repository
• small / lightweight / compact
• performance (speed), fast; efficiency (also: because other SCM was slow)
• small size of repository / very compact repository storage; disk-space efficient; compression (on disk and wire)
• flexibility, power; powerful features; most feature complete
• large number of commands
• modularity, ability to script it / easy to script; hacker-friendly
• Unixy design / UNIX philosophy, 'toolkit' orientation/approach/design
• easy (cheap) branching and merging, lightweight and local (private) branches
  easy to understand branching, and easy to work with multiple persistent branches
  when you make a branch it keeps them all in the one folder
• history rewriting, ability to create a clean/ideal set of patches (amend, rebase)
• filestore / uses filesystem for storage
  easy to create a new repository
  can use it without setting up a server
• single directory containing whole repository; repository (can be) embedded in working directory
  does not clutter the checked out directory (single `.git` directory)
• few dependencies, easy to install
• portable codebase, portability
• cross platform
• easy/simple to setup
• easy publishing
• easy to use
• repositories can be set up on almost every server
• easy to convert from and interact with Subversion (git-svn)
• good support for import/interaction with other SCMs
• patch-management interface layers (StGIT, Guilt)
• handling of renames and moving files (including import from foreign SCM)
  detecting contents copying and movement
• content based tracking
• elegant, clean design (well designed); beautiful underlying model; best design principles; good though out concepts
  easy to understand storage model; the basics (blob, tree, commit, tag) are easy to understand
• history browsing; makes code reviewing easy
• can handle large number of small files with good performance (Source Mage GNU/Linux distribution); Subversion is clumsy on large projects
• scalable (scale well for big repos)
• tools (gitweb, gitk, qgit; gui, visualization tools)
• allows choice of integrating tools
• git-bisect
• blame
• easy to create batch of patches (git-format-patch)
• well documented
• helps you work better, doesn't get in the way
• handling multiple repositories
• detailed output; nice git-log output / more detailed log entries
• cryptographic signing, secure version history
• nice, clean interface
• technically interesting / 'you have control'-factor
• good support for many mature collaboration paradigms
• doesn't impose any paradigm on the developer
• no arbitrary limitations
• index/staging area
• local hooks

Other issues which made responder use Git:

• not satisfied with some other SCM / (small) issues with previous SCM / easier to work with than other SCMs
• needed for kernel development
• some project uses it/switched to it
  my peers use it/peer pressure
  other developers convinced me/recommended it
• best reputation (word of mouth)
• because it is used at Freedesktop.org / some hosting site
• it's from Linus
• Linus Torvalds' backing and the fact that is used by Linux kernel and X.Org means that is not going to go away (not die suddenly like baz and tla did); seems that is here to stay
• GNU Arch is unmaintained/not actively developed
  Because of its similarity to GNU Arch in most ways except for an idiotic maintainer and a death wish.
• natural after BitKeeper
• trying new ideas
• active, large and capable development community / live mailing list
• well maintained, actively maintained; constant evolving development
• used by a number of large, important projects; widely used / widespread (popular); large user base
• hype
• Saw the Linus talk at Google on YouTube and was convinced
  Linus's Google Tech Talk made it sound significantly better than anything else out there
• cool / coolness factor
• of all the distributed systems I played with it first and as a result prefer it.
• help was reasonably easy in coming

Interesting responses:

• It's the most history-oriented VCS I know. There are things you can ask a git history that I hadn't even thought about until I needed them... and Git supports them too
• Trying to keep things in order between a private (corporate) and public (open source) svn via merging was mind-boggling nasty. Svn externals alone didn't suffice because some private commits needed to be made. My only other option would be a stack of patches.
• I immediately liked the design. It's in fact a functional (applicative) data structure. Working on functional data structures every day, so git just felt right.
• It doesn't require symlinks in order to put my home directory configuration files under version control (and SVK didn't work entirely for that).
• I was disappointed with the SCMs available and was getting ready to begin writing my own when Git was announced, being almost exactly what I was looking for.
• Written portably enough that I could port it to Mastodon Linux and ancient versions of BSD without reworking the internals in the process of doing so.
• It felt like distributed SCM made right / Because it is a SCM done right.
• Due to its alleged speed (proved to be mediocre for large workspaces).
• Because Linus called me ugly and stupid ;-)

Note that the answers to this questions are a mix of "why I tried Git" and "why I use Git", with the latter more common. The question was meant to be about why one uses Git (why remains with Git).

12. Why did you choose other SCMs?

TO DO (partial)
606 / 683 non-empty responses

List of features which made user chose SCMs other than Git. Note that one can chose SCMs involuntary... and that it looks like some people answered why they choose other SCMs beside and not insted of Git.

• works on Windows / more Windows compatibility
• CR-LF munging on Windows (note: git now support this)
• works on Mac
• cross-platform support
• easy to use / they just work
• stable
• relatively easy to setup and administer
• centralized control sometimes makes sense; it's clearer with non-git tools
• proper offline work
• patch tracking (git lacks this!) for really intelligent merging
• better CVS, but still the same simple usage model
• conceptual simplicity of the centralized model
• outstanding documentation
• many books on the subject

List of third-party tools, and support for SCM in given application or web application, which made people chose other SCMs

• many plugins for IDEs
• wide variety of plugins and tools
• (better) integration with Trac
• software hosting provides other SCM support
  (e.g. SourceForge provides CVS support)
• no (generic) software hosting site a la SourceForge with Git support
  (there is repo.or.cz, Savannah and Tuxfamily)
• widely used on many community sites such as Gna! (Subversion)

Other issues which made people use other SCMs:

• client requirements
• required in work / company policy
• co-worker familiarity
• used by some project (I was working on)
• needed to track some projects
• existing practice of developers on team
• lot of people have learned it / well known and understood
• because it was standard for so long (CVS), and there were nothing else

Personal issues that made people chose other SCMs

• it was the first one I've learned, so I'm used to it
• lack of knowledge of Git
• I don't care enough to switch

One of issues why one used other SCM is that the project predates Git existence (answers like "it was the only one back then).

13. What would you require from GIT to enable you to change... ?

What would you require from GIT to enable you to change, if you use other SCM for your project?

474 / 683 non-empty responses

List of answers, without count (which for this question is, I think, less important), divided into broad categories, is shown below

Generic:

• being more user-friendly, easier to use
  more friendly output from commands
  better and clearer error messages
  stable command semantics
• reduced number of (visible) commands
  clear separation of plumbing and porcelain
• consistent set of commands
  consistency if command flags
• easier to learn (easier learning curve)
• more stability
• support UTF-16
• A clearer UI. Read the monotone list archive. 70% of the mails are UI related. The result is an clear and easy to use intuitive UI that does what you expect in most cases.

Performance:

• better performance on massive trees (FreeBSD)
• good speed on NTFS (MS Windows)

Documentation:

• a good documentation
  user/installation documentation
  troubleshooting guide
  'Git For Dummies', 'The Git Book'
• documented workflows (including centralized repo workflow, or at least documenting how and why replace it with better workflow)
• development model tutorials
  more example usage
  best practices
  case studies
• guide for designing a branch policy for a shared repository
• screencasts
• documentation in one's native language
• good in-depth administrative documentation
• maybe git-tutor program

Specific features:

• partial-tree checkouts (partial checkout), checking out arbitrary subdirectories
• granular permissions (ACL) within the tree, e.g. restricting translators to the po/ subdirectory
• shallow clone from a given commit: git clone --depth <commit>
• automatic (re)packing
• lightweight working copies
• better and well documented submodule support
• multi-project support / multiple sandboxes support
• git-bind/unbind (like in bzr)
• git-sync
• CVS-compatible syntax as an option
• tracking empty directories
• more friendliness with corporate firewalls
• ability to preserve permissions/modes/EA of files and directories
  access control features / visibility access control
  disabling some users from accessing certain parts of the repository
• being able to merge directories (instead of branches)
• FastCGI gitweb
• some embedded keyword capabilities similar to those provided by CVS and Subversion
• ignore files during merge
• R/W git server (allow push), with NIS, LDAP support
• pull/rebase into dirty tree
• ClearCase dynamic view-like support (externally?)
• better http(s) push via WebDAV: hooks
  working and easy to setup push over https
• plain simple FTP upload (push) and download (clone, fetch)
• better working through corporate firewalls

Portability:

• native MS Windows support, easy installer package, even better support for all platforms; easier setup on Solaris and AIX
• pre-prepared static binaries for FreeBSD, MacOS X, MS Windows
• less dependencies
• support for more platforms
• a portable version of git, one binary + library (gitbox)
• Windows version(s) mentioned on homepage

GUI:

• better (G)UI
  TortoiseGit for MS Windows, or other Windows front-end
  good, advanced GTK+ 2.x tool to visualize git
• history graph connected to file tree in GUIs
• easier management of remotes using GUI
• better diff viewing tools (side-by-side, like KDiff3)

Other SCMs:

• seamless import
  BitKeeper / ClearCase import/sync
  tool to import TeamWare history into Git
• better SCM interop
• SCM Rosetta / "Git for <SCM> users" documentation
• import/export tools supporting incremental import and export
• 100% Subversion interoperability
• git update (stash, fetch, rebase, unstash) a la CVS
• git-svnserve
• svn:externals support

Tools:

• improved administrative tools
• reasonable plugins for IDE (e.g. Visual Studio, KDevelop, NetBeans)
  full Eclipse / NetBeans / IntelliJ support
• good integration with apps like Trac and Bugzilla
  work with continuous integration tools (Cruise Control etc...)
• Git + Launchpad
• libification (for tools support)

Other:

• SourceForge / Gna! / Google Projects support
  (free) hosting with git facilities
  FOSS hosting sites supporting git
• commercial support / corporate backing, contractual service
• number of users, to convince my co-workers that they're not a silly minority; popularity
• projects switching to git
• user education
• marketing, advocacy videos
• convincing coworkers / other members / boss
  willingness of the other developers to learn to use it
• training/certification
• a stop to the constant bashing of other SCMs - this doesn't get you any friends drop the arrogant attitude, work with the rest of the community and try to make something people can understand in an hour
• http://wiki.FreeBSD.org/VersionControl
• At work it'd require some kind of miracle. Huge Perforce repository of highly interrelated stuff in which people can make sweeping changes in a single changelist. Lots of tools that access Perforce. Slow as hell.

14. Did you import your repository from foreign SCM? What SCM?

Answer	Count
N/A	15
No	169
Yes	372
Base	556 / 683
Total (sum)	556

This is only a partial analysis, as it deals only with first part of question. Second part, which SCM, has free-form structure and needed further processing.

One can see that around half of git users have imported (at least one project) from foreign SCM.

15. What tool did you use for import?

Note that one can use more than one tool, for example for different repositories.

Answer	Count
by hand	7
custom script	21
fast-import script	3
Tailor	28
CVS import
git-cvsimport	81
parsecvs	12
fromcvs	2
cvs2git	1
cvstogit	1
Subversion import
git-svn	150
git-svnimport	66
Other SCMs
git-archimport	15
bk2git (customized)	1
darcs2git	4
git-p4	4
git-p4import	1
git-ucmimport	1
hg-to-git	2
hg2git	2
hgpullsvn	1
hgsvn	1
moin2git	1
unspecified	18
N/A	114
Base	467 / 683
Total (sum)	538

16. Do your GIT repository interact with other SCM? Which SCM?

Answer	Count
N/A	35
No	228
Yes	228
Base	491 / 683
Total (sum)	491

This is only partial analysis, as it deals only with first part of question. Second part has free-form structure and needs further processing.

One can see that around third of git users interacts (for at least one project) with foreign SCM, as compared to half of git users which have imported other SCM.

17. What tool did/do you use to interact?

This question is free-form question, but it is treated as multiple-choice question for the purposes of creating table of responses.

Answer	Count
by hand	10
custom script	16
Tailor	4
convert-repo	1
fromcvs	1
git-cvsexportcommit	8
git-cvsimport	19
git-cvsserver	2
git-svn	164
git-svnimport	2
git-p4	4
git-p4import	1
unspecified	2
N/A	153
Base	385 / 683
Total (sum)	388

The only tool which really allows to interact (two-way) with other SCM is git-svn (164 / 232).

How you use GIT

18. Do you use GIT for work, unpaid projects, or both?

Answer	Perc.
work	56	8.2%
unpaid projects	212	31.0%
both	377	55.2%
work + both	433	63.4%
Base	645 / 683
Total (sum)	645

Around two third of people use git at work, or for work.

See also question 55: "Would commercial (paid) support from a support vendor be of interest to you/your organization?"

19. How do you obtain GIT?

Answer	Count	Perc.
binary package	283	41.4%
source tarball	210	30.7%
pull from main repository	153	22.4%
Base	646 / 683
Total (sum)	646

Around half more people use binary packages than source tarball (or source package, I think). More than half of people compile its own git (pull is also followed by compilation).

20. What hardware platforms do you use GIT on?

On Linux it was meant to be result of uname -i. Note however that uname -i does not work on all Unices, as was indicated in help to this question. I'm sorry for this mistake.

Answer	Count
Intel	73
Athlon	2
i386	171
i586	9
i686	60
IA-32	6
IA-64	8
AMD	35
amd64	48
x86	156
x86-64	112
Apple	8
iMac	1
MacBook	7
PowerBook	10
PPC	52
ppc64	7
ARM	6
Alpha	2
PA-RISC	1
parisc64	1
MIPS	1
mips64	1
mipsel	2
SPARC	8
sparc64	6
SUNW	6
Sun-Fire	4
sun4u	3
sun4v	1
k8	1
unknown	67
Base	637 / 683
Total (sum)	875

The above table is in some arbitrary order. It was generated from free-form answers, tabulated as multiple choice answer, as one person can use git on more than one architecture.

Those results probably needs further processing to reduce number of choices, by gathering architectures.

"Unknown" usually means that something else instead of architecture was given (like operating system), or architecture was too generic, like "PC".

21. What OS do you use GIT on?

What OS (please include the version) do you use GIT on?

Answer	Count
AIX	1
FreeBSD	16
OpenBSD	3
HP-UX	1
Linux	582
MS Windows (Cygwin)	22
MS Windows (msys)	1
MS Windows (unsp.)	35
MacOS X / Darwin	94
Solaris	11
SunOS	5
UNIX (unsp.)	1
too many to list	1
MS Windows (together)	58
FreeBSD / OpenBSD	19
Unices (together)	19
Base	645 / 683
Total (sum)	775

The above was generated from free-form answers, tabulated as multiple choice answer, as one person can use git on more than one operating system.

This is not a full analysis of answers, as it does not include operating system version, or (for Linux) distribution(s) used.

22. What projects do you track using GIT?

What projects do you track (or download) using GIT (or git web interface)?

A note: this question was meant to list projects which one tracks, not the ones he/she maintains, meaning the projects in the remotes (section); usually project which is "origin". It was not meant to list all projects which one has under version control using git.

Answer	Count
undisclosed and own projects
own	83
private	19
proprietary	2
configuration files	4
work	38
unspecified	31
Git related projects
git	133
git-gui	1
git-gui-i18n	2
4msysgit	2
msysgit	5
mingw	4
egit	2
grit	1
stgit	5
guilt	2
GSoC projects	1
Giggle	6
qgit	3
qgit4	1
tig	11
Linux kernel and related projects
linux kernel	178
linux-2.4	1
linux-2.6	15
linux-mips	3
linux-mtd	1
linux-omap	3
iwlwifi	5
klibc	1
kvm	4
module-init-tools	1
mtd-utils	1
rt2x00	2
pahole	3
sparse	12
udev	6
wireless-dev	3
kernel related	7
Freedesktop projects
Cairo	21
Compiz	5
Compiz Fusion	6
D-BUS	3
DRM	5
HAL	7
Mesa3D	16
x86info	1
xcb	2
xorg	59
x drivers	3
xf86-video-*	6
xorg * drivers	5
xserver	7
freedesktop	16
Other projects (only those with count >= 5)
ELinks	5
GNOME (git-svn)	8
LilyPond	10
OLPC	12
Rubinius	7
Thousand Parsec	6
U-Boot	8
WINE	29
XMMS2	14
Projects shown (around)	55 / 76
Base	560 / 683
Total (sum)	1123

Footnotes:

Some people wrote URL of hosting site instead of (list of) project names; some wrote 'too many too list' (or equivalent).

All projects were checked and, if not already present, added to GitProjects page on git wiki (except git related projects).

Tracked projects can be divided into the following categories:

• undisclosed: proprietary code / work projects, own projects, etc.
• Linux kernel and kernel related projects (like udev or kvm)
• git related: git, gitk, git-gui, git-gui-i18n, stgit, tig,...
• freedesktop (and related) projects: XCB, Compiz, Mesa3D, Cairo,...
• Linux distributions: Source Mage, Slind, Arch Linux,... (a few)
• tracked via git-svn, e.g. nsd, KDE, GIMP, GNOME, FreeCiv, shell-fm
• others with official git repositories (like XMMS2 or ELinks)
• others with unofficial git repositories (like OpenOffice.org)

I'm not sure if I caught all Linux kernel related projects, and all freedesktop (and related) projects.

There are around 100 (?) different projects tracked mentioned in survey (not all of them choose git as their SCM; some have unofficial git repositories, some are accessed for example via git-svn).

23. How many people do you collaborate with using GIT?

Answer	Count
0	116
1	50
2	45
3	48
4	23
5	41
6	12
7	5
8	11
9-10	47
11-15	30
16-25	26
26-50	17
51-100	17
100+	8
unknown number	79
Base	575 / 683
Total (sum)	575

Footnotes:

24. How big are the repositories that you work on?

TO DO
525 / 683 non-empty responses

Some git repositories have more than 50k files, more than 150k commits, more than 100mb largest file (although not single repository has all those).

25. How many different projects do you manage using GIT?

This question was meant to survey number of repositories one fetches from time to time.

This was a free-form question. For the table below only first number, or first range was taken. For range ('$n-$m' or '$n to $m') the middle of range (($n+m)/2) was used.

Answer (free form)	Count
0	10
1	108
2	84
3	90
4	53
5	51
6	19
7	11
8	12
9-10	39
11-15	26
16-25	22
26-50	19
51-100	5
101+	4
Base	577 / 683
Total (sum)	553

The largest number of projects was 200k (if it is not a mistake), next largest is 410.

As one can see we have here nice Poisson-like distribution: concentrated around low values, with long tail. Well, bit quantized tail, as people write usually "around 20" (or equivalent), usually not remembering exact number of tracked repositories.

Note that answer of '0' might have been given as no answer, or equivalent of 'N/A'.

26. Which porcelains do you use?

Multiple answers (one can use more than one porcelain).

Answer (multiple choice)	Count	Perc.
core-git	558	81.7%
Cogito (deprecated)	56	8.2%
Patch management interfaces:	57	8.3%
StGIT	41	6.0%
Guilt (formerly gq)	13	1.9%
pg (deprecated)	3	0.4%
own scripts	95	13.9%
other	14	2.0%
Base	593 / 683
Total (sum)	780

Those 14 "other" answers make me wish to have provided "if other, what it was?" (sub)question; actually not only for this question.

It is understandable that Cogito still has some users, even though it is deprecated, and (I think) all of its functionality can be found in git-core porcelain. It was meant as SCM / porcelain layer when git-core didn't have it and consisted almost only of plumbing commands.

Quite a bit of people use patch management interface: StGIT, Guilt, even deprecated and abandoned pg (Patchy Git). StGIT has more users than Guilt (formerly gq), although that might be caused by the fact that StGIT was here longer... Some say that it is because of Guilt having non-standalone documentation; it needs reading hgbook, as Guilt concepts are based on mq (Mercurial [patch] queues) extension.

Large number of users use their own scripts, more than any non-standard porcelain. One wonders if this is a result of good git scriptability.

14 users choose other... and there is no "what other" question, unfortunately... From the comments on git mailing list some people answered "other" because they consider git-gui (which is not present in above table) as porcelain rather than just git GUI.

27. Which git GUI do you use?

Multiple answers (one can use more than one GUI). Note that for the first week and a bit of survey "CLI" answer had no explanation that it means command line interface, so results might be bit skewed.

Answer (multiple choice)	Count	Perc.
CLI (command line)	398	58.3%
gitk	347	50.8%
git-gui	123	18.0%
qgit	82	12.0%
gitview	15	2.2%
giggle	48	7.0%
tig	41	6.0%
instaweb	16	2.3%
(h)gct	3	0.4%
qct	3	0.4%
KGit	6	0.9%
git.el	31	4.5%
other	15	2.2%
giggle + gitview	63	9.2%
Base	572 / 683
Total (sum)	1128

As one can see almost as many people use gitk as CLI. Most used GUI are gitk and git-gui, most probably because they are distributed with Git, and because they are portable. QGit is also quite popular, although GTK+ viewers, namely Giggle and GitView, taken together are also very popular (note that there might be instances of users using both Giggle and GitView). I am a bit surprised about popularity of Giggle, I'd say.

Tig (text-mode interface for git) and git.el (GIT mode for Emacs) are also quite popular.

I wonder what are those 15 other GUI. Why oh why there were no "What is this 'other GUI'?" question...

28. Which (main) git web interface do you use for your projects?

Note that this question was single answer. It is possible to serve the same set of repositories using two git web interfaces, for example freedesktop uses both gitweb and cgit interfaces.

Answer	Count	Perc.
gitweb	382	55.9%
cgit	7	1.0%
wit (Ruby)	5	0.7%
git-php	1	0.1%
other	27	4.0%
Base	422 / 683
Total (sum)	422

Around two third (closer to 4/7) of git users use some kind of web interface for their projects.

Most use gitweb (which is distributed with git), 7 use cgit, 5 wit (Ruby), most probably projects sharing site with XMMS2, 1 git-php (I wonder who...), and there are 27 "other" answers, which I am most curious about. What are they?

Some answered "other" as "N/A" (meaning they do not use web interface) instead, what it is not obvious, not answering this question. The explanation that this is possible was added later during duration of survey.

29. How do you publish/propagate your changes?

Multiple choices, as one can use different methods for different projects, for example pushing to public repo for a project maintained, and sending patches via email to participate in third person project development.

Answer	Count	Perc.
push	456	66.8%
pull	220	32.2%
format-patch + email	172	25.2%
pull request	65	9.5%
bundle	13	1.9%
other	70	10.2%
Base	584 / 683
Total (sum)	996

Here "other" means just not listed workflow, although it would be also interesting to know details.

Most popular is push, I guess to public "publishing" repository (and/or probably to mirror repositories). It is twice as popular as next method, gathering more than 3/4 of users.

Pull was supposed to mean logging to public server and pulling changes from private repo, not pulling someone other changes. It is second most popular method.

Sending patches via email is two to three times as popular as sending pull request.

30. Does git.git repository include code produced by you?

Answer	Count	Perc.
Yes	99	14.5%
No	512	75.0%
Base	611 / 683
Total (sum)	611

As it can be seen, only (or perhaps it is that many?) around a 6th to 7th of git users participate in its development by providing code.

Internationalization

31. Is translating GIT required for wider adoption?

Answer	Count	Perc.
Yes	49	7.2%
No	383	56.1%
Somewhat	158	23.1%
Base	590 / 683
Total (sum)	590

More than half of responders doesn't think that translating GIT is required for wider adoption.

32. What do you need translated?

Summary of responses:

• user interface: command messages and error messages
• GUI: git-gui, gitk
• man pages and commands usage ('git <cmd> --help' , git <cmd> --usage')
• user's manual, tutorials, intro, howtos
• website / homepage

Answer	Count
Documentation	60
- man pages	22
- tutorials	14
- user's manual	7
- howto	2
- introductory docs	2
- online help	1
User interface	26
- help	9
- command output	7
- error messages	5
GUI	13
- git-gui	6
- gitk	2
- KGit	1
Homepage	1
Nothing	75
Base	172 / 683
Total (sum)	253

Footnotes:

Answer in subcategory is also counted as answer in category; answers for each of categories or subcategories are counted once. It means that if one answered that he/she wants to have both man pages and user's manual translated it count as "Documentation" category only once. Note that there were answers of for example 'documentation' without specifying details (answer in subcategory).

This free-form question is tabulated (divided into categories) as multiple-choice answer; one can want to have both documentation and user interface translated.

33. For what language do you need translation for?

In alphabetic order, free-form question, treated as multiple choice.

Languages for which git-gui translation exists are marked in italic (state for 12.11.2007).

Answer	Count
Afrikaans	1
Belorussian	1
Chinese	5
Dutch	2
English	3
Filipino	1
Finnish	3
French	21
German	17
Greek	1
Hebrew	1
Hindi	1
Hungarian	1
Italian	4
Japanese	5
Mandarin	1
Norwegian	2
Polish	2
Portuguese	6
Russian	6
Serbian	2
Slovenian	1
Spanish	9
Swedish	2
Tagalog	1
Ukrainian	1
Base	143 / 683
Total (sum)	100

Footnotes:

German and French are most popular. Spanish, Portuguese, Russian, Chinese + Mandarin and Japanese have count 5 or more.

The table below show status of git-gui i18n project, as of 12-11-2007. t is for translated, f is for fuzzy, u is for untranslated, and o for obsolete. Currently there are glossaries only for German (de) and Simplified Chinese (zh_cn) - 34 entries.

Language	Status
German (de)	268t
Hungarian (hu)	268t+6o
Italian (it)	268t
Japanese (ja)	267t+1f
Russian (ru)	245t+20f+3u+5o
Swedish (sv)	268t
Chinese (zh_cn)	59t+38f+168u
git-gui.pot	268

What you think of GIT

34. Overall, how happy are you with GIT?

Answer	Count	Perc.
unhappy	13	1.9%
not so happy	36	5.3%
happy	179	26.2%
very happy	302	44.2%
completely ecstatic	112	16.4%
Base	642 / 683
Total (sum)	642

Nice, git users are mostly very happy with git :-). 13 grumpy users, hmmm...

35. How does GIT compare to other SCM tools you have used?

Answer	Count	Perc.
Better	505	73.9%
Equal (comparable)	96	14.1%
Worse	30	4.4%
N/A	52	7.6%
Base	631 / 683
Total (sum)	631

Clearly Git is superior SCM! (In the minds of Git users at least) ;-) Seriously, one should take into consideration that those results are biased, because it is Git User's Survey, and people usually choose SCM because they think it is best choice.

No answer (null answer) might mean that responder does not use and did not use other SCMs to compare, or at least think that he/she does not have sufficient basis for a comparison.

36. What do you like about using GIT?

TO DO (partial)
578 / 683 non-empty responses

No full analysis yet, and no count of answers, but it seems that the following are encountered most often (or at least those I remember best):

• clean design
• performance (speed)
• size of repository
• reliability, robustness, data integrity
• flexibility, scriptable
• command set, features (git-bisect)
• history rewriting (amend, rebase, interactive rebase, reset)
• history viewers, searching and browsing history
• distributed nature, offline work, full history locally, "local commits"
• easy and in-place branching
• easy merging, includes renames detection
• push/pull via ssh, pull via plain http -- no server needed
• easy to install: few dependencies, portable, lightweight

37. What would you most like to see improved about GIT?

What would you most like to see improved about GIT? (features, bugs, plug-ins, documentation, ...)

512 / 683 non-empty responses

So many suggestions...

First, some of suggestions are actually implemented already, for example git development Changelog (present in the form of RelNotes), shallow clone support, submodules support. This means that new features are not very well announced (which was one of comments here, too).

List of features and improvements mentioned:

• generic behavior:
  • less chatter, clean distinction between success or fail (it it was about git-pull, it is addressed already)
  • better, more verbose error messages, with link to documentation
  • diagnostic output in case of problems; something like git-explain / git-state (this probably would need refactoring, general state info)
  • more universal undo / continue
  • command line consistency, option consistency: getopt / gitopt / optparse
• documentation:
  • unified, organized, searchable documentation
  • The Git Book (c.f. cvs/svn/hgbook); tutorial leading to advanced concepts like rebase, filter-branch, grafts, submodules, gitattributes
  • Git Cookbook / Git Recipes; best practices document, usage scenarios, workflows used, HOWTO
  • Git for Dummies (for people who haven't used SCM at all)
  • more hooks and hook examples
  • mid-level (script / plugin writer level) docs
  • git1line docs a la sed1line.txt
  • "git <cmd> --help" returning one page of short command summary, not manpage; "git help --all --summary" for all command with oneline description
• other SCMs:
  • Cogito migration guide / tutorial (!)
  • other SCM to git (concept, commands) cheat sheet
  • git-bzr (and other SCMs) two-way integration
  • git-svnserve: git functioning as Subversion server
• git-svn:
  • automatic handling svn:externals using submodules and vice versa
  • svnmerge and svk merge markers tracking/marking of merges
• more --interactive:
  • git add --interactive in git-gui: allow to divide hunks
  • git rebase --interactive: graphical interactive rebase in git-gui
  • ncurses-based remote editing (in tig?)
• tools:
  • better Emacs support; Vim plugin; IDE plugins (Eclipse, KDevelop, IntelliJ IDEA,...)
  • MS Windows explorer shell integration; filemanagers integration (Nautilus, Konqueror)
  • side by side diffs in gitweb, a la KDiff3/Meld/ediff etc.
• code:
  • port scripts to C (builtinification)
  • git library (libification)
  • gitbox: single static, pre-packaged binary
• other:
  • bisect dunno / skip / next
  • partial checkout
  • light working copies; multiple working copies per repo
  • git-notes, to annotate commit messages
  • push over sftp
  • option to track empty directories
  • option to track permissions and metainfo: ACL (Access Control List), EA (Extended Attributes), forks / streams
  • rebase and blame merge strategies
  • merge / rebase into dirty tree
  • resumable git-clone; faster and less CPU hungry git-clone
  • checkout/merge/diff/hunk header handlers in distribution for ChangeLog, XML, odf, jar and xul, po files

This is only (large) excerpt, not full list of all requested features. As one can see tabulating (dividing into categories) this data will be not an easy task.

38. What is needed for wider GIT adoption?

If you want to see GIT more widely used, what do you think we could do to make this happen?

459 / 683 non-empty responses

So many suggestions...

Below there is incomplete list of answers, divided into categories. I tried to generalize answers, to reduce size of this summary. Comments in parentheses, emphasized.

Generic:

• Libification
• Maturity, stability
• Ease of use

Portability:

• Better Windows support, including TortoiseSVN like GUI and explorer extension.

(This is I think one of the most requested).

• Portability, better cross-platform support

User interface:

• easy-git: simpler, reduced number of user commands

(Something like now deprecated Cogito? This probably includes better separation of plumbing and porcelain; plumbing should perhaps be not visible to ordinary user. There was also an idea to fold some commands into one, like git-am and git-apply)

• Do usability studies
• Fix inconsistencies and some UI bugs, e.g. too verbose commands. Fix corner cases.
• Improve git commands output and error messages.

Documentation:

• The Git Book (like hgbook and svnbook)
• "Beneath the hood" (technical / programmers manual)
• "When the shit hits the fan" ;-) - advanced usage
• Improve documentation
• Usage scenarios, use cases, recipes / cookbook
• single-file searchable doc, with index (Info version of Git User's Manual, with all manpages in appendix, is perhaps a good start)
• Better documentation for shared repository workflow
• Translated manual, translated documentation

Features:

• Pull and rebase into dirty tree

(There was some work on this using git-stash infrastructure)

• Lightweight working copy a la Bazaar-NG, also known as remote alternates (client-server model)
• Better submodule support
• Integrated GUI merge tool

(Halfway done - git-mergetool calls user defined GUI merge tool; I think it would be nice if git-gui had GUI merge tool included, perhaps "borrowed" from TkDiff / xxdiff)

• Better support for shared repository

Performance:

• Performance on large repositories, on FreeBSD - git is slower than CVS (What filesystem? Is repository packed?)

Tools, interfaces:

• Integration with popular IDE: Eclipse, KDevelop, MSVC, xcode, Rails,... (There is work on Eclipse support)
• More powerful / integrated GUI

(Integrated GUI means lost portability; nevertheless it would be nice to have plugins for Konqueror / KDevelop and Explorer / Visual Studio)

• Better GUI
• Better webgui (web interface)
• Integrate with Launchpad
• Bug tracker (Trac, BugsAnywhere, SCMbug) integration
  (See also grit: stupid in git bug tracker)
• Continuous build tools integration: Continuum, Cruise Control
• Make it have those client/branch history tools like Perforce and Plastic SCM

Other SCMs:

• Rename commands to be more similar to other SCM

(Backward compatibility makes it out of the question).

• Better import tools (best if they would be bundled with git), like parsecvs, cvs2git, fromcvs,...
• Transparent two-way interaction with other SCMs; incremental import; git as fake SCM server, like git-cvsserver or proposed to GSoC git-svnserve
• SCM cheatsheet (comparing commands and concepts).
• SCM migration guides (perhaps also in built-in, distributed docs, not only on-line on git homepage).

Support and marketing:

• Marketing, e.g. articles / blogs about advanced Git usage and features, speeches, presentations and seminars.
• Git blog; feature of the day
• Try to crush 'git is hard' myth
• Friendlier community
• Improved website
• Better advocacy for multirepo workflow, including "please pull" requests
• Distributed SCM advocacy
• Encourage SourceForge / Savannah / Gna! / BerliOS / Google Code to offer git support: git server and sering via http, gitweb or other git web interface, git projects administration (branches, alternates, grafts, tags,...)

(Savannah has some git support, Google Code is rather out of the question)

• Perhaps git repository for CPAN modules
• Move KDE to git
• Bundle in (enterprise) distributions: SuSE, RHEL, Mandriva,...
• Pressure / convince some software vendor to use it internally
• Git Company - paid support service

One of the more striking (and funny):

• Big fat posters world-wide with Catherine Zeta-Jones stating how happy she is since she switched to git ;-)
  She can actually write C-code.
• Offer Git stickers to put on laptops and such

Changes in GIT

(Since year ago, or since you started using it).

39. Did you participate in previous Git User's Survey?

Answer	Count	Perc.
Yes	51	7.5%
No	583	85.4%
Base	634 / 683
Total (sum)	634

51 people did out of 634 who answered this question, out of 115 (?) who did participate in the previous survey. Around half. Bit curious.

40. What improvements you wanted got implemented?

TO TABULATE
129 / 683 non-empty responses

41. What improvements you wanted didn't get implemented?

TO TABULATE
104 / 683 non-empty responses

42. How do you compare current version with version from year ago?

Should be: from year ago, or since you started using Git. No responses (303 / 683) might be caused by the fact that one do not use git for a year, so he/she doesn't know what git looked like year ago.

Answer	Count	Perc.
Better	319	46.7%
No changes	60	8.8%
Worse	1	0.1%
Base	380 / 683
Total (sum)	380

Most think that git has improved. Single malcontent: only one user thinks that Git is worse than year ago; I wonder why...

43. Which of the new features do you use?

Multiple choice; the list does not include all new features. Some new features are not visible at first glance, and one uses them without conscious choice.

Answer	Count	Perc.
git-gui	103	15.1%
blame improvements	74	10.8%
detached HEAD	71	10.4%
stash	68	10.0%
mergetool	67	9.8%
interactive rebase	66	9.7%
reflog	54	7.9%
submodules	52	7.6%
shallow clone	31	4.5%
commit template	24	3.5%
eol conversion	22	3.2%
gitattributes	21	3.1%
bundle	17	2.5%
worktree	17	2.5%
Base	255 / 683
Total (sum)	687

This table is sorted by count.

Detached HEAD support and stash command were long requested; no wonder they are popular.

Documentation

Summary of "Do you find X useful?" questions

Usefulness of	Yes	Some	No	Base
GIT wiki	191	69	198	458
on line help	377	172	28	577
distributed help	425	154	22	601
individual responses				683

44. Do you use the GIT wiki?

Answer	Count	Perc.
Yes	316	46.3%
No	300	43.9%
Base	616 / 683
Total (sum)	616

45. Do you find GIT wiki useful?

Answer	Count	Perc.
Yes	191	28.0%
No	69	10.1%
Somewhat	198	29.0%
Base	458 / 683
Total (sum)	458

46. Do you contribute to GIT wiki?

Answer	Count	Perc.
Yes	17	2.5%
No	460	67.3%
Corrections and removing spam	45	6.6%
Base	522 / 683
Total (sum)	522

47. Do you find GIT on-line help (homepage, documentation) useful?

Answer	Count	Perc.
Yes	377	55.2%
No	28	4.1%
Somewhat	172	25.2%
Base	577 / 683
Total (sum)	577

48. Do you find help distributed with GIT useful?

Do you find help distributed with GIT useful (manpages, manual, tutorial, HOWTO, release notes)?

Answer	Count	Perc.
Yes	425	62.2%
No	22	3.2%
Somewhat	154	22.5%
Base	601 / 683
Total (sum)	601

49. Did/Do you contribute to GIT documentation?

Answer	Count	Perc.
Yes	43	6.3%
No	551	80.7%
Base	594 / 683
Total (sum)	594

50. What could be improved on the GIT homepage?

GIT homepage was, at the time of this survey, at http://git.or.cz

171 / 683 non-empty responses

List of answers, without count, divided into broad categories.
Some answers were hard to classify into one section, so please read carefully.

Generic

• Keep it always up-to-date!
• Catch up with the latest version in kernel.org/.../RPMS.
• Publicity. Until the survey I didn't know it had all that! (There is a homepage?)
• More active movement between IRC/list and FAQs
• Less Linux programmer focused.
• Translations to other languages for better adaption elsewhere.
• A dedicated domain name, easy to remember and find. Nicer URL? (git.org?)
• Change the site name to have 'git' in it! Like 'TheGitSite.com' rather than git.qk.wkx.or (it is git.or.cz) or whatever.
• It could use a better URL than 'git.or.cz'; the URL looks like a mirror and I'm not sure I'm on the official home page.
• Git could use a real logo.

Code and design

• Could be more sexy.
• Graphical design.
• Give it some nice & fresh design.
• Make it more attractive.
• Color scheme (?)
• Better design and appreciation for aesthetics. For the typical 'programmer' whose position is 'who cares what it looks like' they won't care. For the managers and other folks that need to be convinced it will look more polished and professional. Appearances matter.
• Move the details on fetching the development code to the 'getting git' page.
• More prominent links to documentation on how to get started with GIT.
• More bling :-) but I'm not really sure about that. Non-technical users get scared away anyway.
• Smarten it up with some color and graphics.
• Maybe get a graphics monkey and make it less dull but otherwise the content is OK.
• Make it prettier. Sounds silly but it counts. Bazaar's main feature is a pretty website ;).
• The layout. It's OK for me but it looks like a minor hobby project's page
• Make it easier to find information. Reorganization to find the most important information easily.
• The page has too much info and is hard to navigate. Look at http://www.mozilla.com/ for contrast.
• Better layout to make things easier to find. It seems busy and hard to find things. Simplify.
• Move the documentation up to the top. It's what people want to access the most!
• Perhaps divide it again into separate pages if it grows
• The layout and the organization of the sections. It's pretty hard to know why should I use git just looking at the webpage.
• A proper side bar for things that are currently in boxes.
• Hide the rarer commands and special tricks deeper and emphasize the best usage practices.
• Less text on the front page, less text per page
• Web 2.0 type interface as Ruby and Ubuntu have.
• Pictures. Fancy layout.
• Less clutter. I find it somewhat unstructured.
• Modern styles look and feel.
• Download link needs to stand out more. The homepage appears rather 'flat' that is nothing stands out as more important than the rest. In order of importance, I think there should be:
  1. Download
  2. Git Quick-start Guide
  3. Documentation
• The lines are too long. Try to find a better proportion.
• It doesn't look like a project home page. Mercurial does a better job with the look of their page IMHO.
• Make it less monolithic. Stick documentation on its own page, methods of acquiring GIT on its own page and so forth. That allows more room for each without making one huge homepage.
• Divide content up into sets of info related to tasks a person would be interested in
  • getting a first setup
  • maintaining/updates
  • introductory documentation
  • reference/refresh-memory info
  • project/git-developer info
• Make it look more modern but don't use too many web features (i.e. make sure it works on elinks).

Documentation

• Link to Git User's Manual and not only to crash course/tutorial. Feature the User Manual more prominently
• More documentation. More tutorials and examples. More workflow examples, more crash courses.
• More links to documentation/tutorials/howto
• Recipes for how to do things with git. Examples and workflows. Common pitfalls.
• More visible link to the tutorial.
• Old documentation removed / updated (index, staging, cache).
• Less emphasis on cogito / Remove Cogito references.
• Remove more aggressively outdated documentation for historic tools (like cogito).
• Fluxograms describing some use cases. Perhaps some diagrams.
• More comprehensive tutorial with optional boxouts.
• Up to date information about best practices and recommended tools.
• Add a new users section with some walkthroughs that show how to use git practically on a real repository. Maybe add comparable commands from other SCMs. (git clone -> cvs checkout)
• 'git for svn/cvs people' could use an overhaul (at least they did a few months ago) The Git for SVN users tutorial is incomplete and does not explain for example how the index works and why it's there. Thus people end up thinking that 'svn add' is like 'git add' whereas it's not.
• A 'git features tour' showing the great features git has.
• Add some material for presenting git to others (slides)
• Add a tutorial helping deal with a conflict merge.
• Feature-driven help: a list of features with short tutorial on how to use each one.
• Example of interacting with CVS repository (import, export, cvsserver)
• Highlight those pieces of documentation that aren't easily available through --help and man 'git-something'.
• Getting started for new users.
• Simple online demo and beginner Tutorial on one page. The demo could be an applet giving access to a terminal of a running virtual machine with git and some demo repositories. The virtual machine is reset every full hour.
• Some way to indicate which version of Git a specific piece of documentation refers to.
• Missing information: examples of ways different (real) projects use Git.
• More details on how to make a centralized workflow work
• A prominent 'Why git?' or 'Why distributed?' section might be good.
• Better SVN -> Git

Downloads

• It could be more up-to-date about new git versions (sometimes it lags behind a bit).
• Catch up with the latest version in kernel.org/.../RPMS.
• Current official version should include the one on master.
  Snapshots. Results of nightly builds and tests. There should be links to download pu/next/master/maint branches tar.gz trees (snapshots) from gitweb).
• Information about Windows version(s). Easier for windows users to find msysGit (maybe with a development warning) under 'Getting git'. Links to windows ports: http://code.google.com/p/msysgit/ and a plea for help.
• Download link needs to stand out more.
• Download repository for the most common distros (Ubuntu, RedHat / Fedora Core, SuSE).
• Provide processed man pages to install. Provide PDF documentation

Information, new links, new features

• What's New section
• News and info about where things are going (roadmap).
• Link to the latest release announcement. Now you can only find a link to the tarball but most of the time I only want to take a quick look at the announcement (RelNotes).
• Add a news section and maybe some pointers to interesting user-contributed HOWTOs or something.
• Add more external porcelains like Guilt to the frontpage.
• Recommended 'out-of-the-box' package of GUI or CLI interface.
• Cogito state should be better clarified.
• Bring the porcelains list up-to-date -- in particular mark Cogito (cg) as outright deprecated.
• More information on project around GIT (like GUIs etc).
• Perhaps making some pages like FAQ or Tips and Tricks, or discussion about nature of branches in git taken from GitWiki when they are mature enough
• I wish for Git Traffic: digest of git mailing list discussions (there was one at http://kerneltraffic.org/git/index.html but it stopped after one issue; KernelTraffic is also no longer updated).
  Some type of recent news collected from the mailing list 'what's new in the latest release' or coming-soon previews would be nice.
• The layout and the organization of the sections. It's pretty hard to know why should I use git just looking at the webpage.
• More marketing on what projects use git and perhaps more blurb on why git is better than other SCMs.
• Easier access to release notes and changelogs (i.e. the history) without having to browse the git repo or read separate pages from the documentation.
• A blog or news page (not everyone enjoys mailing lists), perhaps link to mailing list archive
• Provide 'A note from the maintainer' as a prominent link probably named as 'How the git project is managed and how to participate'
• Place links to direct git's plugins core and tools source tree.
• Link to some good GUIs. Giggle is a good GUI that serves my needs.

One person seems to mistake git documentation page ("reprint of the man pages") at http://www.kernel.org/pub/software/scm/git/docs/ for the homepage, another mistook (kernel.org?) gitweb for it.

Here is short summary of most common answers, with a short comment if appropriate:

Generic:

• Dedicated domain name / site name, e.g. git.org or git.com to have it look less like mirror or unofficial page

(git.or.cz still comes first when searching Google for "git"; current domain name was available to homepage admin - historical reason)

DONE: git.com and git.org are taken (squatters), git-scm.org points now to git homepage.

• Better design: make it prettier, easier to find information, move more important things first, use sidebar instead of boxes, perhaps divide it into separate pages (again). But make sure it works on Elinks for example.

(IIRC pasky is not web designer, so help is appreciated)

Documentation:

• More documentation: tutorials, workflow examples, walkthroughs, SCM commands comparison, interacting with other SCMs, HOWTOs, best practices, recommended tools, fluxograms describing use cases (graphics). Make link to Git User's Manual stand out better.
• Less emphasis on Cogito, mark it more explicitly as deprecated and slowly try to get rid of Cogito references in documentation (e.g. crash courses).

(Cogito is officially deprecated from not a long time; the process of removing references to cg in crash courses is AFAIK ongoing)

Partially DONE

• More emphasis on "Why git?" and "Why distributed SCM?". A 'git features tour' showing the great features git has. In short: why and when to choose git.

(Someone would have to write it)

• Simple online demo. The demo could be an applet giving access to a terminal of a running virtual machine with git and some demo repositories. The virtual machine is reset every full hour.

(This might be a good idea, but I think it is a bit hard to do from technical point of view; at least securely, securing against intrusion and, perhaps accidental, denial of service)

Downloads:

• More up-to-date about new git versions.

(With one person updating homepage, who is not git maintainer...)

DONE. The info about latest version is updated using script. If homepage is not updated, then there is bug in this script, and you should [bugreport].

• There should be links to download pu/next/master/maint branches tar.gz trees (snapshots) from gitweb.

(The source snapshot part is quite easy to do, but it might increase load on kernel.org / repo.or.cz, unless snapshots are somehow cached)

Denied

• Results of nightly builds and tests. Static binaries for other OS (FreeBSD, MacOS X).

(There is a matter of machine park. Somewhere those nightly builds, perhaps together with nightly running of test suite, have to run.)

• Information about MS Windows version(s). Link to MSys Git, marking it as under development; perhaps plea for help?
• Provide processed man pages to install. Provide PDF documentation, at least PDF version of Git User's Manual.

(Having PDF version is quite new; there is no manual.pdf target in official Makefile.)

Information, new links, new features:

• Link to the latest release announcement (RelNotes) on download page.

(Links to RelNotes are in HTML version of git(7) manpage, but I think it is not enough. Fortunately we _have_ release notes.)

DONE

• News section, info about where things are going (roadmap)

(Junio has a hard time maintaining TODO, and git doesn't have roadmap AFAICT)

• Provide 'A note from the maintainer' as a prominent link probably named as 'How the git project is managed and how to participate'

(That is a good idea I think, better than having it on GitWiki. We can put direct link to SubmittingPatches nearby.)

• I wish for Git Traffic: digest of git mailing list discussions. Some type of recent news collected from the mailing list 'what's new in the latest release' or coming-soon previews would be nice.

(There was one at http://kerneltraffic.org/git/index.html but it stopped after one issue; KernelTraffic is also no longer updated. Any volunteers?)

• Links to more tools, GUIs, version control interface layers. A somewhat related request: copy pages like FAQ or Tips and Tricks, or discussion about branches from GitWiki when they are mature enough.

(For example there was requests to put links to / info about Guilt and Giggle on git homepage. Giggle has quite a bit of users among GUIs).

ONGOING. Lately tig (text interface for git) was added to tools section of git homepage

51. What topics would you like to have on GIT wiki?

GIT wiki was, at the time of this survey, at http://git.or.cz/gitwiki

134 / 683 non-empty responses

See also: Wanted pages

Note that anybody can edit pages on GIT wiki, so if you want to have some information, some topic to be present on wiki, best solution would be to simply create resp. page, or add info to existing page. This question was meant to be the place to gather requests for topics for which one doesn't know enough to write or doesn't have time to write.

List of answers, without count, divided into categories. Each category starts with pages for which there is proposed PageName, and ends with pages which are better for other media.

Generic:

• more tips and tricks

Documentation:

• GitRecipes / GitCookbook, i.e. examples on how to solve some problem, e.g. two-way interaction between git and svn repos, setting up automatic commit emails, setting up gitweb, setting up git server, pushing through firewall, setting up HTTP server for write / push access, discussion of different workflows
• QuickRef / GitCheatSheet; quick hints, quickref
• eclectic / untypical use cases, for example: GitForBackup, SyncWithGit, GitForDocuments (LaTeX, ODF,...), MergingProjects (for example gitweb, gitk, git-gui with git)
• CentralizedRepository / CentralRepository / SharedRepository (description of CVS/SVN-like workflow)
• advanced usage, for example FindingErrorsWithBisect
• workflows, usage scenarios, use cases, collaboration paradigms including KernelWorkflows (kernel maintainer tasks / workflows), BestPractices, etc.
• HOWTOs (perhaps wikifying some files from Documentation/howto)
• Git for newbies: quick start document (rather for homepage)
• The Git Book (for homepage and/or bundled documentation)
• 'A typical day with Git' tutorial (for homepage and/or bundled documentation)
• Guided tour (certainly for homepage, wiki doesn't have infrastructure)
• git code / API documentation (most certainly *not* wiki)
• git internals intro (?)

Features and planned features:

• MergingStrategies / MergeStrategies i.e. wikified Documentation/merge-strategies.txt, perhaps with proposed merge strategies and revctrl / other SCM merge strategies described
• BranchingAndMerging (there is BranchesInGit wiki page)
• docs for new features, including: KeywordExpansion, EolConversion, GitAttributes, ShallowClone, SubmodulesSupport / SubprojectSupport, DetachedHEAD, BundleTransport / GitBundle, AutoRepacking / AutoPacking
• concept documentation, including BranchesInGit (existing), WhatIsTheIndex (existing), GraftPoint (existing)
• FileRename, including discussion on tracking vs detecting renames

Maintained:

• outstanding issues
• status page for requested features
• roadmap

Other SCMs:

• SCMInteraction <some> SCM (svk/svn/cvs/p4) interaction
• Git for <some> SCM users, e.g. GitSvnComparison (rather for homepage)
• SCM commands equiv and concepts comparison aka. SCMRosetta
• SCM migration guides

Examples:

• HooksExamples / GitHooks (example hooks)

Other:

• GitConventions / CommitConventions for example commit message conventions, sign-off, etc.
• GitForSingleDeveloper (perhaps as a part of WhyVersionControl)
• SyncWithGit for example synchronization between laptop and desktop
• PublishingRepository, i.e. description of most typical workflow with private repository and public bare publishing repository (or repositories)
• GitServerSetup (tutorial)
• pitfalls
• Tips and tricks of the day (short)

52. What could be improved in GIT documentation?

190 / 683 non-empty responses

List of answers, without count, divided into categories. I tried to generalize answers, not to list all 190 answers.

Generic:

• More examples of not-so-common setups
• Translation, also known as i18n
• Proof-reading by an expert technical writer
• Single document, searchable documentation, so one can search all of the git documentation at once (includes unified tutorial)
• Documentation is way too detailed. Needs overview of tasks. Existing overviews seems to miss some important things.
• Make documentation more feature-oriented / task-oriented / goal-oriented, so one doesn't have to know the exact name of command to use. It's hard to find informations on 'how' to do a thing you think git is able to do but that you don't know yet.
• More verbosity. 'Reasons-why' something is done this and that way in git
• Remove references to Cogito (which is deprecated) in documentation
• Just make it more complete. When I was reading the GIT mailing list I would see tricks that I couldn't find in the man pages.
• Document concepts: What is the index? What does packfile contain? What is an object? (user's manual, core tutorial and git(7) try to explain this; and there is git glossary).
• Understanding the git paradigm... need a good metaphor to make clear what the index is and why it exists.
• The current documentation is either too shallow (the quick start things) or a bit difficult for beginners.
• Separate the detailed in-depth documentation from the higher level usage documentation. Again go look at Mercurial's stuff. When I'm using the VCS I don't need detail I need simple to understand what's going to happen next information and feedback.
• Better organization
• Too complex
• Make git documentation more consistent (style, contents, writing)
• Giving more information how the tools work together.
• Less jargon
• More elementary examples

New documentation:

• 'Git for Dummies' / 'Git for newbies'. A document for really dumb users showing that git is very easy. How to start using git from the perspective of someone not used to revision control systems at all.
  Show one way to solve typical problems. Newbies are not interested in solving problems in several ways.
• 'The Git Book' (with panda-bear on cover, or other animal: pony perhaps?). Something like SVNBook and hgbook (for Mercurial)
• 'Git Recipes' / 'Git Cookbook'
  The user manual is a big step forward in my opinion. I think more cookbook style things would be helpful for when you need to solve a specific problem. The wiki would be a great place for these.
• Introduction and in-depth examples of application in different types of projects
• Introductory documentation needed for users working on patch series; on fringes of kernel project, e.g. cooperation on projects that rebase frequently are common.
• Use cases (including fluxograms). More documentation for common use cases.
• Workflows, push and pull examples for different team situations. Structures and processes for multi-developer collaboration. More examples of common tasks. More complex examples for different work flows, preferably with a good rationale.
• Intermediate / mid-level documentation (explanation: Documentation seems to be either at porcelain or coder / plumbing level. As I wanted to use read-tree etc. differently, more mid-level documentation would have helped.)
• Improved migration guides from other SCMs and from other SCM workflows; step by step migration / conversion tutorial.
• Installation documentation for using a 'central' git server and gitweb. How to do centralized [repo] development with git.
• HOWTOs (there are some)
• Technical documentation: API if possible (doxygen?), RFC for index and pack formats, RFC for pack (git) protocol, explanation for dumb protocol exchange, explanation of SSH protocol exchange
• A single alphabetical list of all commands in one index somewhere.
  I hate the splash-page 'categorized' list. (separate doc, or in git(7) manpage).
• Better overview documentation of git concepts / git jargon, perhaps with diagrams (better than glossary). Try to avoid jargon.
• Windows specific documentation

Manpages improvements:

• When a git command implements (allows) options from another command (for example git-show and git-log), document this EXTREMELY clear and never do it halfway (document some forget others). Document all options. Have more examples of all those examples within the documentation or have more cross-references to them.
• Repeat certain bits of knowledge here and there: it's important to make sure that users reading only one section still understand what's going on.
• Document all environmental variables (even plumbing)
• Organization. There should probably be more cross-linking of topics and referencing. The diff options are not well described in git-log because it is not primarily a diff command. Yet they are frequently used options. Similarly the syntax for referencing an object (including extended sha1 syntax: $commit^, $commit~$n, $commit:$path, etc.) is used all over the place but there are often no references. I know where to find it but a user reading the git-show manpage for the first time doesn't know that it's the right command for finding an old revision of a file.
• Better cross-references in man-pages, improved linking with related commands ('to revert the effect of this command see git-foo')
• Put helpful info in sections related to widely-used high-level tools (porcelain), NOT pieces of plumbing that had their documentation written first.
• Document push/pull/clone interaction
• Better documentation on submodules.
• Make the git commands better documented for newbies and the more experienced users
• Better description of the arguments (especially for those not used with the new terminology).
• Document merging, stages in the index during merge (in git-merge / git-pull manpage, as this is in user manual already)
• Add a task-oriented index besides the command-oriented one in git(7). Better overview of the main commands.
• More examples of usage / example uses for commands. Have example in every man page.
• Document how higher-level commands use the lower-level commands in the individual manpages; maybe a documentation page on how to create your own git commands using the plumbing (the latter perhaps in user's manual).
• More examples for exotic use cases... e.g. git over ssh where the git binaries are not in the path... something like: $ git-clone --upload-pack=/home/foo/git-upload-pack ssh://... which by the way is a killer feature.
• Consistency. The 'SPECIFYING REVISIONS' part is one of the most important ones in the documentation and keeping it on git-rev-parse page is bad (hard to find and the different formats are not easy to eyeball from the page). Move to git(7) maybe?
• Higher level and more thorough documentation. What does a command do (not just its options)? What does each option do (bad: manpages that state they only document some options)?
• Explanations for /why/ the examples are done the way they are done.
• In addition to explaining what the tools do, also take a paragraph to explain how each feature should fit into an ideal workflow, i.e. it's place in the big picture not just it's purpose. More explanations of how to use features and how they interact instead of just isolated documentation of what that feature does.
• Better separation of plumbing and porcelain. Perhaps classification of tools also in individual manpages?

Other documentation improvements:

• Enhance Git User's Manual
• Manual is incomplete, tutorial(s) much too short
• Remove controversies from Git User's Manual
• Document meanings of error message (unless improved)
• The tutorial needs a complete rewrite. It's simultaneous too detailed and not informative enough.
• More of it -- tutorials on everything. The nice thing about Python for example is a massive easy tutorial that covers everything.
• Add explanation of frequent/typical errors of users not accustomed to git, and how to correct them (presumably to Git User's Manual).
• Explain every funny file in .git (either in git(7), in glossary or in Git User's Manual).
• More Tips&Tricks: features like rebase -i comes to mind (most probably in tutorial or user's manual)
• Tutorial / user's manual should consist of the following parts: simple usage (single developer), networking and syncing DBs, trust system (workflow).

Building and installation:

• Ship man pages and don't make user's generate them (for example git.spec can have two sources: git and git-manpages)
• Install manpages to proper place by default, not `~/bin` (?)
• Documentation in dead tree format (Git User's Manual or The Git Book).
• info docs
• Produce as PDF (I guess tutorials, or manual, or future gitbook)
• stop using AsciiDoc (single answer)

Bugs in documentation:

• As far as I can tell many man pages don't show all of the options available for their command. I've had to find out about some options by looking at shell script sources.
• Keeping up-to-date with the actual functionality of Git. (Adding features should always be accompanied with documentation fixes).
• More consistency between options on command line at the top (usage, syntax) and the actual options described.
• Correct spelling and punctuation.
• On OS X in the man pages there's the text '.sp' after every '.'.
• On Linux with asciidoc 7.1.2, xmlto 0.0.18, docbook-style-xsl 1.68.1, compiled manpages have '.ft C ... .ft' around some literal blocks (examples of command output etc.)
• Doesn't seem to display properly in Safari--looks like a text encoding problem.

Other issues:

• All online documentation should mention which version they refer too
  (already done, I think)

Getting help, staying in touch

Summary of "Do you use X?" questions from "Documentation" and "Getting help" sections

Do you use	Yes	No	Base
GIT wiki	316	300	616
mailing list	204	406	610
IRC channel	182	376	558
individual responses			683

Summary of "Do you find X useful?" question sfrom "Documentation" and "Getting help" sections

Usefulness of	Yes	Some	No	Base
GIT wiki	191	69	198	458
mailing list	146	79	34	259
IRC channel	127	59	26	212
individual responses				683

As one can see mailing list is the primary medium for git, and IRC secondary (auxiliary) one.

53. Have you tried to get GIT help from other people?

Answer	Count	Perc.
Yes	357	52.3%
No	261	38.2%
N/A (no answer)	65	9.5%
Base	618 / 683
Total (sum)	618

Half users needed help. It might be that Git is not documented enough; it might be that version control is not an easy task.

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

NOTE: in this table percentage is the number of people who answered this question, not the number of people who participated in the survey, because of "if yes" part.

Answer	Count	% sum
Yes	326	86.0%
No	53	14.0%
Base	379 / 683
Total (sum)	379

That is I think very good (around 86%) percentage.

55. Would commercial support be of interest?

Would commercial (paid) support from a support vendor be of interest to you/your organization?

Answer	Count	Perc.
Not Applicable	203	29.7%
Yes	69	10.1%
No	322	47.1%
Yes + No	391	57.2%
Base	594 / 683
Total (sum)	594

The percentage in the table above is of number of people participating in survey, not number of people who answered this question.

Only 69 (12%) of answers yes, 322 no, 203 not applicable (which meant to encompass people who do not use git at and for work).

433 = 56 + 377 people participating in this survey use git for work, or for both work and unpaid projects (as compared to 391 who answered this question not with N/A).

Note that Git is GPLv2, and it will probably stay that forever, so you are free to start a commercial support scheme for Git, but others are free not to choose it. This question is to get to know if there is sufficient demand for commercial Git support for it to be viable.

56. Do you read the mailing list?

Answer	Count	Perc.
Yes	204	29.9%
No	406	59.4%
Base	610 / 683
Total (sum)	610

The fact that only one third of git users are reading mailing list (which is nevertheless quite large percentage) means that features have to be documented somewhere besides mailing list archive and logs (commit messages).

Note that the number of people who answered question decreases, which probably mean that this survey is just too long.

57. If yes, do you find the mailing list useful?

Answer	Count	% sum
Yes	146	56.4%
No	34	13.1%
Somewhat	79	30.5%
Base	259 / 683
Total (sum)	259	100%

Only a small percentage of people reading git mailing list doesn't find it useful. Good.

58. Do you find traffic levels on GIT mailing list OK?

If you read git mailing list of course.

Answer	Count	% sum
Yes	193	79.5%
No	50	20.6%
Base	243 / 683
Total (sum)	243	100.0%

59. Do you use the IRC channel (#git on irc.freenode.net)?

Answer	Count	Perc.
Yes	182	26.6%
No	376	55.1%
Base	558 / 683
Total (sum)	558	81.7%

Lack of answers most probably means either: I did not known about #git channel (and therefore do not use it), or that this survey is too long and I didn't answer last questions...

60. If yes, do you find IRC channel useful?

Answer	Count	% sum
Yes	127	59.9%
No	26	12.3%
Somewhat	59	27.8%
Base	212 / 683
Total (sum)	212	100.0%

Most people who use #git channel find it useful.

61. What could be improved in getting help?

Did you have problems getting GIT help on mailing list or on IRC channel? What were it? What could be improved?

99 / 683 non-empty responses

Problems and suggestion for mailing list:

• I answered my own question and no one even commented it. User and development discussion should be separated. Just release announcements in the user list.

You need another mailing list for users. The current mailing list is very developer centric.

The mailing list feels like it's more for developers rather than users and it's a little intimidating to ask newbie questions there. Maybe separate git-users and git-dev lists would make sense.

Git mailing list needs a users and developers list. Mixing up the two is intimidating with all the traffic and the number of patches and advanced topics that shoot around.

Having separate git-users and git-devel lists would be nice. I might read both but I hate to ask a newbie question on a list where 50% of the submissions contain patches.

(Other users find mailing list very responsive. Splitting the list into either git-devel and git-users, or git and git-announce has its advantages and disadvantages. You can always filter out patch submission and comments on patches thanks to the "[PATCH]" prefix convention present on mailing list.)

• A question or two with no response at all. In hindsight my query was way too long-winded but it's still frustrating to be ignored.

I answered my own question and no one even commented it.

(See above.)

• The git mailing list is too high traffic to remain on. Maybe split it into a few lower traffic versions?

Biggest problem is that smaller problems are getting lost in the growing size of the mailing list.

The sheer amount of traffic makes the mailing list hard to deal with sometimes. Getting your email tools set up correctly can help (i.e. auto tag+archive in GMail), but ultimately you still have to wade around in hundreds of emails you don't care about in order to find the ones you do care about.

(Most people find traffic levels on git mailing list OK, see question 58.)

• Will not go through corporate firewall.

(I think it was about mailing list, but perhaps it was about IRC)

• I no longer subscribe to the GIT mailing list as ML subscription is forbidden at my new job, and I have no time at home to read it all.

(You can read git mailing list through many archives / web interfaces, including MARC and GMane ones, and through NNTP (aka. Usenet, aka news) interface on GMane: see MailingLists. You don't need to be subscribed to git mailing list to post.)

• People responded quickly to mailing list queries usually helpfully. However there was occasionally a touch of annoying 'groupthink' to the responses; sometimes new users are just confused and really would be better served by just changing their working habits, but other times there appeared to be a bit of tunnel-vision on the part of the longtime git users.
• Trolls could be thrown out ;-) Seriously we had only a few there, but they are mighty annoying.
• Mostly no. But little help on applying email-patches in win32 using GMail. I'll get there though :)

(Late addition of smtpserver (with ability to select port number), smtpuser, smtppass and smtpssl configuration variables / options to git-send-email should help with sending patches using GMail. As to applying email-patches, git-am understand both mbox and maildir formats, not that it help much with win32 mail programs; but you can always try to save email in raw format from GMail WWW interface)

Problems and suggestions for IRC:

• The IRC channel has too few people who know answers to questions; if you're there at the wrong time of day when none of them happen to be around it's useless. But if you're there at the right time it's pretty good.
• IRC channel seems to respond to newbie git users quite well, but mid-level experience often gets no response.
• Traffic on the IRC channel is a bit high. It may need to be split into a few different high-level topics in the near future.

(IRC channel or git mailing list? I don't remember IRC channel having high traffic...)

• It's hard to improve IRC. It's such a poor medium for understanding the communication going on.

(On the other hand it is responsive. I think pastebins helps to sidestep limitations of the medium. Nevertheless the main medium of communication is git mailing list, not #git channel.)

• IRC is blocked from work :-( I may try it by tunneling out.

(Any suggestions here?)

Generic problems and suggestions:

• Sometimes you get no answer (on git mailing list or #git channel) but that happens
• People seem to think the problem isn't with git, and yet I find git extremely buggy and non-intuitive. Your "Git in 5 minutes" doesn't even include +x a hook or mention of hooks; neither does Linus speech. If you don't +x a hook, try to figure out what is going on. I dare you. Git fails silently a bunch, maybe half of the time by design. Which shouldn't be acceptable.

Try addressing an ssh address in URL format: it isn't consistent and it will fail in half the apps. Same thing with git-ls-remote: it might have an --upload-pack that works, but this isn't across the board! From my own debugging none of the shell scripts have an --upload-pack option that work.

(Not here. This is question about getting help from people, not about documentation or what you find hardest in GIT.)

• After the last thread the GIT FAQ is almost begging for a 'Please don't ask about C++' section.

(Truly, Git FAQ (which resides here on Git wiki, but perhaps we should consider extracting it and adding to distribution tarballs) needs maintenance, updating and adding new frequently asked questions. Currently there is no FAQ maintainer.)

The other side: getting help success stories:

• Quite the contrary. When Source Mage GNU/Linux switched to using GIT our developers spent a considerable amount of time asking questions and discussing features and bugs on #git. The feedback that we got was fabulous: the GIT developers were helpful interested in our needs and productive when it came to fixing bugs. One bug we discovered was even handled by Linus Torvalds himself and in just a matter of hours! In our eyes the GIT development community gained rightful reputation as one of the most friendly and helpful communities there is.
• No, the mailing list has been very responsive. I have never asked a question on IRC but I sometimes answer newbie questions.
• Mailing list is very interesting especially as I'm working on egit. IRC is more immediately helpful.
• I'd like to say that I consider #git to be the most useful IRC channel I've ever been to when it came to getting answers to my questions. Thanks guys!

The IRC channel is wonderful. The people there do a good job with questions.

• No problems. In fact the mailing list/IRC could substitute the documentation but I guess that
  1. does not work in offline mode
  2. is going to get on peoples nerves after a while (recurring questions)

Open forum

62. Other comments and suggestions

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

141 / 683 non-empty responses

There are many "keep up the great work!" (and equivalent) as answers to this questions, and a few "worst SCM I've used". Those are excluded from the lists below.

Suggestions for git:

• One of the biggest complaints I hear is that Mercurial's UI is much more 'intuitive' and user friendly. Perhaps looking at it's operation and comparing/contrasting would be good.

(Note that changing names of commands for example might be impossible because of historical reasons and large usebase. On the other hand perhaps this is just a steep learning curve, unavoidable for a power tool.)

• Mercurial has an excellent tutorial which had my team up and running in less than a hour after a week struggling to make git do anything useful.

(I hope that late work on "Git User's Manual" helps here)

• Handling of Unicode (UTF-16 encoded) files is a big pain with git. Even SVN can do a diff of them.

(The idea that blob is just a bag of bytes will not change; but we have input/output filters, and soon before-diff filters, connected with gitattributes)

• I like how in Subversion the commands work relative to the current directory. With Git I always seem to be dealing with longer paths and/or have to change to the root.

(Running git from within directory deep within repository structure should 'just work'. If not, then it is an error... unless in situation like referring to tree-ish, where path is almost always relative to project root).

• Keep up the UI simplification and make sure the docs start off with usage somewhat similar to CVS/SVN. I think many users are scared by Git because they see the more powerful commands thrown around too early and get scared.

Git is just too complicated for a typical project. I understand it's probably great for the Linux kernel but for a smaller project like mine (Mesa) it's overkill and a frustration. (...) With git everything seems hard. (...) I've wasted hours trying to figure out git. That alone is a huge issue. I guess I could go into specific details about my problems with git but I've already spent enough time on this survey.

(If you want git to be improved, you should specify details of your problems with git, either should have in this survey (now closed), or now send email to git mailing list (which does not need subscription to post))

• Figure out why people find git hard to learn and eliminate those barriers to entry. Make git more task-oriented rather than data-model-oriented the way it is now.

It's a great idea and a powerful tool but it's got a long way to go before it reaches wider adoption because it's so damn hard to use.

(...) I'm evaluating Mercurial despite its being based on Python because it feels cleaner and simpler to use. I would prefer to use Git.

(I think the 1.4 and 1.5 series is a good step in simplifying git for simple tasks and ordinary user. Core git porcelain improved much, and now there is no need to use plumbing for every-day tasks.)

• No one-pager cheat sheet with the 6 most basic commands on it so people can go use git.

(This got corrected. There is git cheat sheet on the Internet; there is link to it on GitLinks page, and you can take a look here: GitCheatSheet.)

• Having a git library where other apps can integrate git, along with bindings for Python would be great.

Make it easier to use by graphical clients like KGit.

(The libification project from Google Summer of Code would help there, I think)

• I think that moving away from shell scripts to builtins is a necessary step but I don't really like it. It would help if you kept them around, perhaps in contrib/, so that others can learn how to use the plumbing (I learned a lot about git from reading these shell scripts).

(Doing it: shell scripts which are moved to builtin are retired to contrib/examples/ directory).

• Building git is a pain. (SHA1 sources being a problem). Can't git use autoconf? Also I've heard people have issues with git's portability (for example some BSD variant). Shell scrips weren't portable to non bash IIRC and often relied on GNU extensions in some programs. Native Windows port is also important.

Probably the toughest challenge for Git IMO is that Mercurial, Darcs and Bazaar are good and similar. Lack of Windows support makes some people rule out Git altogether even though it may be better overall.

I'd like to just stress support for windows and central repositories. (...) In fact most of my friends really wanted to use git but they wanted a solid native port.

I think key to the adoption of git is that it is made to run on Windows as well as the other major OSes.

(Git tries to use autoconf in a way that is totally optional, to do detection and write options for Makefile; you are welcome to contribute to configure.ac. People work on making git more portable, for example trying to make it work with dash, defining in the meantime minimal POSIX-like shell compatibility required. Native MinGW Windows port is in the development)

• I think that it is very nice that git is in the native OS repositories for Fedora. The Debian version needs updating.

(git Makefile has rpm target, and git.spec target; perhaps this is the cause)

• git-blame is manageable (with gc and reduced history etc) but that slowness still seems to be a negative point for many of my peers. I wouldn't mind better performance there either. Maybe some kind of optional indexing for those who want fast blame?

(I recall there were some ideas about how to make git-blame faster on git mailing list. Making it interactive for graphical blame tools reduced latency; there is I think a bit place for easy improvement for reblaming. Maybe packv4 would help with blame performance... What is I think unchangeable is the fact that snapshot driven / whole history driven SCMs always would be slower at least a bit than single-file based SCMs. This tradeoff is not possible to avoid. But don't forget that git has other tools for examining history, like path (subsystem) limiting, searching commit messages, pickaxe search and graphical history browsing tools like gitk or qgit.)

• Get a mascot perhaps O'Reilly animal for O'Reilly GitBook (Git User's Manual) like the svnbook.

(What animal could Git use for O'Reilly? Herd of horses, or a pony?)

• I'm wondering what the overall goal is - git's origin as a neutral ground was fine but it hasn't seemed to take off as a viable alternative for general use. Do you care about that? Is it OK that git is it's own little niche?

Suggestions about git mailing list:

• Git adoption will be limited by the actions and attitudes of those on the mailing list. 'If you can't say anything nice...'

(We are nice, I think... to a point. But perhaps attitude needs some improving.)

• The ML had way too much traffic. I think there should be at least a git-patches@ where people submit there patches and git@ remains for user/dev discussions.

(Most users find level of traffic on git mailing list O.K. It is not that hard to separate patch submission and their discussion from the rest of traffic thanks to [PATCH] prefix convention used.)

Suggestions and comments about this survey:

• Various questions need 'other' options such as the programming language question. Various questions that already have 'other' as a possible choice need a text box to fill in the specifics.

(I am not sure if it is possible mixing radiobutton/checkbox with text field with currently used free survey service, survey.net.nz)

• The text fields (and text areas) of this survey are way too small!

(I am not sure if changing this is possible with currently used free survey service, survey.net.nz)

• You should do a survey of feature requests.

(See questions 13, 38, 41 and especially 37)

• Shorten survey length. This survey is too damn long. Make the survey shorter!

Cut down the number of questions on this survey by a factor of 4.

(I think removing the questions which asks very similar question but in different context be a good start. But that aside: which questions should be dropped, which concatenated (and which split); which are useful and which are not?)

• Questions not asked: what can be improved on GitWiki, workflows used and tools used, kind of repository hosting used for project, programming experience level and version control experience, using git for non-programming repositories like ikiwiki or documents, perceived git stability and number of bugs.

(The surveys is very long as it is now. Those questions are nice, but it would make survey too long I think.)

• The survey asks about new features that are not in a stable version of git yet. git-stash comes to mind. This is silly. Not everybody will track your development branch. I certainly don't. I don't for other SCMs I use either.

(I tried to put only features which are in released, i.e. numbered, version. git-stash is in 1.5.3, see Documentation/RelNotes-1.5.3.txt)

• Regarding Q19 (How do you obtain GIT?). I actually use all three forms on different systems.
  • Mac: pull from MacPorts
  • Ubuntu: from git.git
  • remote systems: tar balls.

(Should it be made multiple choice question, then?)

• From survey maintainer: reduce number of free-form questions if possible. Move to multiple choice or single choice questions, with 'other' being one of answers and question below to explain what 'other' mean. This way we can have easy analysis of coded response form question with flexibility of free-form question.

Some other comments:

• I've been so busy with other projects. I didn't realize so many interfaces exist. Thanks to this survey I'll spend some time checking out the wiki for the other interfaces.

I didn't even know about any of the new git features listed in question 43.

I need to get an up to date version as there are things mentioned in this survey that I don't know about.

• At the 'Solutions Linux 2007' exhibition in Paris I have been looking for a service provider that could propose some training sessions for Git. I couldn't find one. Maybe in 2008...
• Perhaps we should have git blog, with at least "What's in", "Note from maintainer" and "MSysGit herald" announcements.

References

• Git User's Survey 2007 at Survey.Net.
• Git User's Survey 2007 thread on git mailing list: discussion about questions etc.
• GitSurvey2006 - previous survey summary
• GitSurvey2006vs2007 - comparison of 2006 and 2007 (this one) survey results.
• Mercurial UserSurvey, which inspired first Git User's Survey.
  See also comments about Mercurial User's Survey 2007

---