All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC] Git User's Survey 2010 (resend)
Date: Sun, 4 Jul 2010 10:13:35 +0200	[thread overview]
Message-ID: <201007041013.40563.jnareb@gmail.com> (raw)
In-Reply-To: <AANLkTilD8N6rnj9e3KzRB7_q3J0I4cJGx5EduX_UJScC@mail.gmail.com>

On Sun, 4 Jul 2010, Ævar Arnfjörð Bjarmason wrote:
> 2010/7/3 Jakub Narebski <jnareb@gmail.com>:

[...]
> > == Getting started with Git ==
> >
> > === 03. Have you found Git easy to learn? ===
> > (single choice)
> >
> > * Very easy
> > * Easy
> > * Reasonably easy
> > * Hard
> > * Very hard
> >
> > === 04. Have you found Git easy to use? ===
> > (single choice)
> >
> > * Very easy
> > * Easy
> > * Reasonably easy
> > * Hard
> > * Very hard
> >
> > NOTES:
> > ^^^^^^
> > Those two questions, considered alone, doesn't tell us much.  If one use
> > git, then usually one does not think it is too hard to use (unless forced to
> > use git by external circumstances, like project he/she works on using git).
> > On the other hand those two questions together give us some mesaure of git
> > learning curve, telling us if people consider git easy to use but hard to
> > learn, or vice versa ;-)
> >
> > I think it might be also good to have to calculate correlations, e.g. if
> > people who find git hard to use make use of its advanced features.
> >
> > The question is: should they stay, or should they go?
> 
> They should probably stay. But they don't really ask the right
> question IMO. Which is not whether users think it's difficult to
> learn, but whether it's unreasonably difficult for the problem they're
> solving.
> 
> I.e. jet aircraft are hard to operate, but they also do neat
> stuff. How hard is Git to learn for the problem it's solving?

The problem is how to formulate question about this issue.  We cannot
really ask about perceived accidental and essential (inherent)
complexity, can we?

Perhaps something like this:

=== xx. Have you found distributed version control easy? ===
(multiple choice)

 + Very easy
 + Easy
 + Reasonably easy
 + Hard
 + Very hard

Or something like that, with separate question if DVCS is difficult
or not.

Alternatively we could ask about _relative_ ease of learning / use.
But I don't think this would go well (and I don't think we could get
good answers from that).

[...] 
> > === 14. How do you fetch/get changes from upstream repositories? ===
> > (multiple choice, with other)
> >
> >  + git protocol        (e.g. git://git.example.com/repo.git)
> >  + ssh                 (e.g. ssh+git://git.example.com/repo.git,
> >                             git.example.com:/srv/scm/repo.git)
> >  + http                (e.g. http://git.example.com/repo.git)
> >  + rsync (DEPRECATED)  (e.g. rsync://git.example.com/repo.git)
> >  + filesystem          (e.g. /path/to/repo.git, file:///path/to/repo.git)
> >  + via git-bundle
> >  + foreign SCM (e.g. git-svn)
> >
> >  + Other, please specify
> 
> Maybe git format-patch -> git am. Since it's already this complete.

Does anybody use git-format-patch + git-am for *fetching* (and cloning)?

[...]
> > === 17. Which of the following features would you like to see implemented in git? ===
> > (multiple choice)
> >
> >  + better support for big files (large media)
> >  + resumable clone/fetch (and other remote operations)
> >  + GitTorrent Protocol, or git-mirror
> >  + lazy clone / on-demand fetching of object
> >  + support for tracking empty directories
> >  + environmental variables in config,
> >   and expanding ~ and ~user in paths in config
> >  + better undo/abort/continue, and for more commands
> >  + '-n' like option for each command, which describes what would happen
> >  + side-by-side diffs and/or color-words diff in gitweb
> >  + admin and/or write features in gitweb
> >  + graphical history view in gitweb
> >  + GUI for rebase in git-gui
> >  + GUI for creating repository in git-gui
> >  + filename encoding (in repository vs in filesystem)
> >  + git push --create
> >  + localization of command-line messages
> >  + wholesame directory rename detection
> >  + graphical merge tool integrated with git-gui
> >  + union checkouts (some files from one branch, some from other)
> >  + advisory locking / "this file is being edited"
> >  + "commands issued" (or "command equivalents") in git-gui / gitk
> >  + warn before/when rewriting published history
> >  + built-in gitjour/bananajour support
> >  + syntax highlighting in git-gui
> >
> >  + other (describe below)
> >
> > NOTES:
> > ^^^^^^
> > This is new question, a multiple choice companion to a essay free-form
> > question below.  Included are a few example features (some from
> > partial analysis of "19. What features would you like implemented in
> > Git?" question in 2009 survey.
> >
> > What features should be mentioned besides those above?  What criteria
> > should we have for including features in this list?
> 
> I think "submodules that Just Work(TM)" or something similar should be
> included. I.e. something the user doesn't have to worry about anymore
> than they do a normal tree entry. Git's complex submodule support is
> something I often hear complaints about.

I'll add 'better submodule support' to this list.

[...] 
> > === 27. Which communication channel(s) do you use? ===
> >        Do you read the mailing list, or watch IRC channel?
> > (multiple choice)
> >
> >  + git@vger.kernel.org (main)
> >  + Git for Human Beings (Google Group)
> >  + msysGit
> >  + #git IRC channel
> >  + #git-devel IRC channel
> >  + #github or #gitorious IRC channel
> >  + #revctrl IRC channel
> >
> > NOTES:
> > ^^^^^^
> > Are there any communication channels that I have missed?  For example
> > is there a separate channel that JGit/EGit developers use?
> 
> FWIW: There were two non-bots on #git-devel when I joined it.

Well, Git User's Surveys always served more or less accidentally as
the source of information about git and git community ("we have wiki?"
from the first survey ;-))

> > == About this survey. Open forum. ==
> >
> > === 28. How did you hear about this Git User's Survey? ===
> > (single choice, with other)
> >
> >  * git mailing list
> >  * git-related mailing list (e.g. msysGit)
> >  * mailing list or forum of some project
> >  * #git IRC channel topic
> >  * announcement on IRC channel
> >  * git homepage
> >  * git wiki
> >  * git hosting site (or blog related to such site)
> >  * software-related web site
> >  * news or social news site (e.g. Digg, Reddit)
> >  * blog (or blog planet)
> >  * other kind of web site
> >  * Twitter or other microblogging platform
> >
> >  * other - please specify
> >
> > NOTES:
> > ^^^^^^
> > This list would of course be updated to reflect the list of (planned)
> > announcement channels.
> >
> > There of course will be announcement on Git Mailing List, and perhaps
> > also on msysGit list / Google Group, and on Git For Human Beings
> > Google Group (if it exists).  I'll announce it on #git, and ask op to
> > put short announcement in channel description, and I can announce it
> > on other IRC channels.  I would add announcement to main page of Git
> > Wiki, and as Git Homepage administrator to put announcement about Git
> > User's Survey.
> >
> > I usually tried to contact administrators of git hosting sites,
> > including git.kernel.org, repo.or.cz, GitHub, Gitorious, Assembla,
> > Codebase and Unfuddle, asking them to put announcement about
> > Git User's Survey either somewhere on the site, or in their blog
> > (if there is any).  What git hosting sites it is worth to ask?
> >
> > Sidenote: I am thinking about contacting different git hosting sites
> > _before_ staring survey, asking them (them = administrators) about
> > what questions would they like to see.  Do you think thet it is good
> > idea?
> 
> Yes, definitely.

Which ones?  I'll definitely contact GitHub, try to contact J.H. about
git.kernel.org and pasky about repo.or.cz, and contact admins/contact
of Assembla, Codebase, Unfuddle.  Who else to contact?

> 
> > Should I try to post announcement on mailing list for projects that
> > use git?  There are entirely too many such projects nowadays, and such
> > announcement can be considered spamming by some...
> 
> Yeah. Definitely for the big ones like the "Projects using Git" listed
> on git-scm.com. I don't think it'll be considered spam.

The questions is: which ones are big?  Those on Git Homepage?  Those
on "Git (software)" page on Git Wiki?  Which ones to try to contact
besides those on this list (and what list if there is '?' here)?

 * Linux kernel (LKML)
 * Android (?)

 * Debian (DWN list / wiki)
 * Fedora (?)
 * openSUSE (?)

 * GIMP (?)
 * GNOME (newren's blog?)
 * jQuery? (?)
 * OLPC? (olpc-devel?)
 * Perl (perlbuzz, some Perl blogger?)
 * Ruby on Rails (RubyForge, ?)
 * Samba? (mailin list IIRC?)
 * VLC? (vlc mailing list)
 * Wine? (?)
 * X.Org (freedesktop.org wiki?)

Sidenote: I can also try to post announcement on various wikis that
host some (more or less specific) information about how to do git
development for given project.

> > I would like to have announcement of Git User's Survey 2010 at
> > LWN.net, but this would need to be send at least two weeks in advance,
> > if I remember correctly.  Is it worth it?  What other news site should
> > I (or you) send announcement to?
> 
> reddit, digg, hackernews, slashdot, ...

Reddit, Digg and HackerNews are social news sites, and all require
having some official (or at least official-sounding) already existing
page with official announcement (GMane link, or GitWiki page?).  All
would also rquire upvoting...
 
> > If you can Digg / Reddit announcment on some site, please do.  I can
> > announce Git User's Survey 2-1- at Twitter, Identi.ca and Plurk, but I
> > don't have wide area of followers.  So please RT.
> >
> > Should we contact some bloggers (besides asking Junio to put
> > announcement on his blog) to post an anouncement?  Which bloggers
> > would respond positively (perhaps Linus...)?

I can try to contact masukomi[1] (Kate Rhodes) and rtomayko[2]
(Ryan Tomayko), both of whom have written positively about Git
in the past, Junio C Hamano[3] of course, and perhaps also
Linus Torvalds[4]

[1] http://weblog.masukomi.org/
[2] http://tomayko.com/
[3] http://gitster.livejournal.com/
[4] http://torvalds-family.blogspot.com/

You all can help, of course...

-- 
Jakub Narebski
Poland

  reply	other threads:[~2010-07-04  8:14 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-03 19:58 [RFC] Git User's Survey 2010 (resend) Jakub Narebski
2010-07-04  0:21 ` Ævar Arnfjörð Bjarmason
2010-07-04  8:13   ` Jakub Narebski [this message]
2010-07-07  9:18     ` Yann Dirson
2010-07-07 21:43       ` Jakub Narebski
2010-07-10 11:01   ` Felipe Contreras
2010-07-04  9:07 ` David Bainbridge
2010-07-04 11:14   ` Jakub Narebski
2010-07-04 20:48     ` David Bainbridge
2010-07-05  7:19       ` Jakub Narebski
2010-07-04 22:43 ` Scott Chacon
2010-07-04 23:48   ` Jakub Narebski
2010-07-07 12:28 ` Yann Dirson
2010-07-07 21:37   ` Jakub Narebski
2010-07-08  7:24     ` Yann Dirson
2010-07-10 11:31 ` Felipe Contreras
2010-07-10 19:58   ` Jakub Narebski
2010-07-11  9:57     ` Felipe Contreras
2010-07-11 17:42       ` Jakub Narebski
2010-07-12 10:14         ` David Bainbridge
2010-07-12 10:19           ` Felipe Contreras
2010-07-12 10:22             ` David Bainbridge
2010-08-09 21:59 ` Felipe Contreras
2010-08-10 22:16   ` Jakub Narebski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201007041013.40563.jnareb@gmail.com \
    --to=jnareb@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.