This is continuation of partial summary of Git User's Survey 2007, ending at state from 28 September 2007. (response ident "46f95167c967b"). The survey can be found here: http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9 http://tinyurl.com/26774s The data this summary is base on can be found here: ---- There were 683 individual responses Other SCMs ~~~~~~~~~~ 13. What would you require from GIT to enable you to change, if you use other SCM for your project? TO DO 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 administative 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 conected 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. Getting help, staying in touch ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 61. Did you have problems getting GIT help on mailing list or on IRC channel? What were it? What could be improved? TO TABULARIZE 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 throught NNTP (aka. Usenet, aka news) interface on GMane. 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 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. What other comments or suggestions do you have, that are not covered by the questions above? TO DO 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. 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 on GitWiki to it) * 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 projects 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? (Junio, Linus?) 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) * 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?) 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... -- Jakub Narebski (away from Internet) - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
