This is continuation of partial summary of Git User's Survey 2007, ending at state from 28 September 2007. The survey can be found here: http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9 http://tinyurl.com/26774s The data this summary is based on can be found here: http://git.or.cz/gitwiki/GitSurvey2007?action=AttachFile&do=get&target=surveydata.csv http://tinyurl.com/yusomo ---- There were 683 individual responses About you ~~~~~~~~~ 00. Date of response Date | Count ------------------------------------------ Before | 7 During | 584 After | 92 ------------------------------------------ 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 survey's 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). If anyone is interested I can provide full date by date histogram. Getting started with GIT ~~~~~~~~~~~~~~~~~~~~~~~~ 07. What helped you most in learning to use it? TO DO 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 (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; 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 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 * lerning to use it as maintainer maintaining "perfect patch series", keeping history clean rewritig 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 peple in the community (on the mailing list) * setting up gitweb * having to use CLI interface * no <some language> documentation More interesting: * 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 nonlinear history. How you use GIT ~~~~~~~~~~~~~~~ 22. What projects do you track (or download) using GIT (or git web interface)? TO TABULARIZE 560 / 683 non-empty responses 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). Tracked projects can be divided into the following categories: * undisclosed: proprietary code / work projects, own projects, etc. * Linux kernel an 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,... (a few) * tracked via git-svn, e.g. nsd, KDE, GIMP, FreeCiv * others with official git repositories (like XMMS2 or ELinks) * others with unofficial git repositories (like OpenOffice.org) There are more that 100 different projects tracked mentioned in survey (not all of them _choose_ git as their SCM). Internationalization ~~~~~~~~~~~~~~~~~~~~ 32. What do you need translated? TO TABULARIZE 172 / 683 non-empty responses Summary of responses, without count (which I guess is most important): * 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 -- Jakub Narebski Poland (temporarily away from Internet) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Mike Travis | [RFC 00/15] x86_64: Optimize percpu accesses |
| Nick Piggin | Re: [PATCH 0 of 4] Generic AIO by scheduling stacks |
| Trent Piepho | [PATCH] [POWERPC] Improve (in|out)_beXX() asm code |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Kevin Ballard | Re: git on MacOSX and files with decomposed utf-8 file names |
| Jon Smirl | ! [rejected] master -> master (non-fast forward) |
| Linus Torvalds | Re: kernel.org mirroring (Re: [GIT PULL] MMC update) |
| Nguyen Thai Ngoc Duy | Re: VCS comparison table |
| Leon Dippenaar | New tcp stack attack |
| Richard Stallman | Real men don't attack straw men |
| Kevin Neff | Patching a SSH 'Weakness' |
| Chris | sudo & wheel group |
| David Miller | [GIT]: Networking |
| Wang Chen | [PATCH 2/15] netdevice 82596: Convert directly reference of netdev->priv to net... |
| Valentine Barshak | [PATCH] USB: net: Fix asix read transfer buffer allocations. |
| Natalie Protasevich | [BUG] New Kernel Bugs |
