Git User's Survey 2008 partial summary

Git User's Survey 2008 partial summary

[Jakub Narebski]

This is partial summary of Git User's Survey 2008 after more that 1000 
(yes, that is more than _thousands_ responses) just after the 3 days
of running the survey.  It is based on "Analysis" page for this survey:
  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8

We have around 1045 individual responses (including 20 responses in the 
'testing' channel), as compared to 683 individual responses for 2007 
survey, and (I think) 115 answers (Base = 115) for 2006 survey. 
That is quite a lot, especially after so short time since staring the 
survey.


03. With which programming languages are you proficient?

Around 939 people answered this question.  C is most popular with 59%;
Ruby and surprisingly a bit shell script programming have around second
place, with about 52-53%.  More people are proficient with Python than 
in Perl by about 1/3-1/4.  Very few people (25 responses, around 3%)
feel proficient in Tcl/Tk, which means shallow pool of possible git-gui
and gitk contributors.  Java is quite popular with around 42%, which
gives hope in continued JGit/EGit development.

And finally 12 responses (around 1%) of "I am not a programmer".  That's 
nice.  That's very nice.


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

Among more interesting replies in the "Other (please specify)" section
were:
 * tracking 3rd party projects, especially with git-svn
   (which probably should be one of possible responses)
 * versioned filesystem
 * distributing teaching examples live
   (which admittedly is form of "sharing data or sync" response)
 * real-time collaborative editing (conspire)
 * as a sandbox, to debug changes performed by binary installers
 * storing automated build test results

Work projects and unpaid projects constitute almost the same amount.


17. How do you obtain Git?

Most people use binary packages (59%), with source packages and tarballs
second (28%) and pull from main repository third (22%).

Note that in this version of survey this question is multiple choice 
(multiple answers), as opposed to single choice in earlier surveys.


18. What operating system do you use Git on?

Linux, then MacOS X, then MS Windows.  In "Other, please specify"
there are two responses of 'iPhone OS'... can one use git on iPhone?


21. Which porcelains / interfaces / implementations do you use?

Most people (99%, 862/869) use core-git in some form, perhaps in 
addition to some other interface.  Cogito no longer has large
amount of users: only 5; it looks like people noticed finally that
is deprecated and not maintained any longer.  Among patch management 
interfaces StGIT dominates with 24 (3% share), then newcomer TopGit 
with 13, and last Guilt with 6; but the last part can be caused by 
people not noticing it among answers, as I saw a few of "Guilt"/"guilt"
among free-form "Other (please specify)".  Patchy GIT (pg), long
deprecated, has happily no users.

"My own scrips" with 117 / 13% responses shows very well either good
Git scriptability, or lack of good UI ;-).  I guess it is the former.

"Other" responses include Grit, which I forgot is at least partially 
(re)implementation of Git, git-wtf and gc-utils... but some of 'other' 
responses include tools which are (I think) neither porcelain, like 
gitosis or gibak, or git-cola, or magit, but more of a GUI.

People who do not use "git (core)" implementation use StGIT, own 
scripts, or Easy Git.


22. Which git GUI (commit tool or history viewer, or both) do you use?

I think it should have been stated more clearly that this list includes 
also integration with IDE, RAD and editors.  Here among tools which I 
forgot to add are magit which is another Emacs interface, and Textmate 
bundle.

Hmmm... only 75% people use command line; it means that graphical tools 
improved.  Tools which are distributed along git, namely Tcl/Tk based 
git-gui and gitk dominates.  Bit suprising for me is third place (if we 
exclude CLI) of GitNub, and 6% of tig users.  QGit is fourth with 11%;
Giggle has more users (26) than GitView (4).  Quite new GitX has 
surprisingly as much as 16 (2%) users. 

Among 'others' there is nice and a bit curious "testing the integration 
in upcoming KDevelop 4" (which was GSoC 2008 project for KDE).


23. Which git web interface do you use for your projects/have installed?

It was meant to be about web interface _you_ run, and not only use as a 
part of third party git hosting site you use.  It is a bit strange that 
people put GitHub there, unless GitHub source code was made available, 
or is it possible to deploy/install clone of GitHub yourself.

As before gitweb dominates with 80% of share, then Gitorious with 14% 
and next cgit with 11% (30 responses).  

Among 'others' there are Trac (I guess Trac plugin), Redmine 
(I guess also plugin), ikiwiki and "my own, not public yet".



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

746 individual responses, 9% yes (66 replies), 69% no, 22% not 
applicable.


To be continued...
-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> This is partial summary of Git User's Survey 2008 [...]
> 
> 03. With which programming languages are you proficient?
> 
> Around 939 people answered this question.  C is most popular with 59%;
> Ruby and surprisingly a bit shell script programming have around second
> place, with about 52-53%.  More people are proficient with Python than 
> in Perl by about 1/3-1/4.  Very few people (25 responses, around 3%)
> feel proficient in Tcl/Tk, which means shallow pool of possible git-gui
> and gitk contributors.  Java is quite popular with around 42%, which
> gives hope in continued JGit/EGit development.

Yea, I liked seeing that result from our user base.  42% of the
respondants know Java as a language.  Not all of them may like
programming in it for fun, but at least they claim they know it.  :-)

In the IDE part Eclipse received 13% (124 responses), which is
almost close to Emacs (20%, 193 responses).  Sadly only 2% (19
responses) use EGit.  There's probably a lot of reasons for that.
Possibly the "egit_sux" tag on repo.or.cz.  Or our lack of a stable
update site that users can install reasonably stable versions from.


I think we've picked up 3 new contributors recently to the JGit/EGit
project.  Jonas Fonseca has started to use JGit inside of a NetBeans
IDE plugin.  Today he posted 2 patches, hopefully the first of many.

Tor Arne Vestb� has been working on improving EGit's resource
decorator.  His fork on repo.or.cz is a few days old, but it has
some really good potential in there.  I'm looking forward to seeing
the final series from his work.

Charles O'Farrell joined us a few weeks back and added support for
ref deletion, along with CLI for "jgit branch -d/-D".  I think his
time is rather limited, but the contributions are most appreciated.

And of course Marek Zawirski is still contributing, but I think
he's back in classes so his time is a little bit more constrained.

Months back I think someone asked about including JGit in a
commerically licensed product.  Since its 3-clause BSD its quite
possible to do.  But I haven't seen anything materialize yet on
that front.

-- 
Shawn.

Re: Git User's Survey 2008 partial summary

[David Brown]

On Wed, Sep 03, 2008 at 04:07:19PM +0200, Jakub Narebski wrote:

>18. What operating system do you use Git on?
>
>Linux, then MacOS X, then MS Windows.  In "Other, please specify"
>there are two responses of 'iPhone OS'... can one use git on iPhone?

Probably not too difficult if the phone has been hacked, since it's
mostly a stripped down OSX.

David

Re: Git User's Survey 2008 partial summary

[H.Merijn Brand]

On Wed, 3 Sep 2008 07:45:52 -0700, "Shawn O. Pearce"
<spearce@spearce.org> wrote:

> Jakub Narebski <jnareb@gmail.com> wrote:
> > This is partial summary of Git User's Survey 2008 [...]
> > 
> > 03. With which programming languages are you proficient?
> > 
> > Around 939 people answered this question.  C is most popular with 59%;
> > Ruby and surprisingly a bit shell script programming have around second
> > place, with about 52-53%.  More people are proficient with Python than 
> > in Perl by about 1/3-1/4.  Very few people (25 responses, around 3%)
> > feel proficient in Tcl/Tk, which means shallow pool of possible git-gui
> > and gitk contributors.

Rewrite them in perl or python and get more patches?
The fact that it is not perl withheld me from finding solutions to
problems I still have with the git-gui gitk combination

> > Java is quite popular with around 42%, which
> > gives hope in continued JGit/EGit development.

I would love to use git in Eclipse, but I tried again this week and
found the following problems

1. egit web site does not give you any clue about installation or
   integration with eclipse or how that could be done at all
2. I found no suitable eclipse-egit package for OpenSUSE 10.3, and the
   packages I /did/ find depended on packages not available for SuSE
   10.3

> Yea, I liked seeing that result from our user base.  42% of the
> respondants know Java as a language.  Not all of them may like
> programming in it for fun, but at least they claim they know it.  :-)

I *hate* programming in Eclipse, but some java projects here require me
to work with it. My preferred IDE is elvis (a vi clone)

> In the IDE part Eclipse received 13% (124 responses), which is
> almost close to Emacs (20%, 193 responses).  Sadly only 2% (19
> responses) use EGit.  There's probably a lot of reasons for that.
> Possibly the "egit_sux" tag on repo.or.cz.  Or our lack of a stable
> update site that users can install reasonably stable versions from.

/me fiercely nods!

-- 
H.Merijn Brand          Amsterdam Perl Mongers  http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, SuSE 10.1, 10.2, and 10.3, AIX 5.2, and Cygwin.
http://mirrors.develooper.com/hpux/           http://www.test-smoke.org/
http://qa.perl.org      http://www.goldmark.org/jeff/stupid-disclaimers/

Re: Git User's Survey 2008 partial summary

[Scott Chacon]

On Wed, Sep 3, 2008 at 7:07 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> This is partial summary of Git User's Survey 2008 after more that 1000
> (yes, that is more than _thousands_ responses) just after the 3 days
> of running the survey.  It is based on "Analysis" page for this survey:
>  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8
>

Is there a way to download the raw data?  There may be some
interesting correlations between answers in different fields I would
like to look for in the data, but it's too aggregated here.  I heard
it would be available at the end, but can I get it from somewhere now
as well?

Scott

Re: Git User's Survey 2008 partial summary

[Jakub Narebski]

On Wed, 3 September 2008, Scott Chacon wrote:
> On Wed, Sep 3, 2008 at 7:07 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> > This is partial summary of Git User's Survey 2008 after more that 1000
> > (yes, that is more than _thousands_ responses) just after the 3 days
> > of running the survey.  It is based on "Analysis" page for this survey:
> >  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8
> 
> Is there a way to download the raw data?  There may be some
> interesting correlations between answers in different fields I would
> like to look for in the data, but it's too aggregated here.  I heard
> it would be available at the end, but can I get it from somewhere now
> as well?

I, as survey administrator, can export survey data to CSV or Excel
formats, but currently I cannot export URL to such data.  So you can
either ask me to send you such data[*1*] (CSV for around 700 individual
responses weights 1.7MB, and 272KB after gzipping), or sign in
to Survs.com (which might, or might not, require invite) and ask me
to add to "git" role/account/group.

On the other hand you can use different filters (again, I think only
survey administrator can do this, or whatever role is it) to limit
summarized replies, for example show summary only for users which
use Git on MS Windows (answered "What operating system..." question,
and the answer was "MS Windows (Cygwin)" or "MS Windows (msysGit)".

I can also enable individual responses in shared view (above link),
so you can see reply by reply; but I don't think this is particularly
useful, especially with 1000+ responses (21 in 'testing' channel).


[*1*] I will not send this to git mailing list...
-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary

[Felipe Contreras]

On Wed, Sep 3, 2008 at 6:20 PM, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> On Wed, 3 Sep 2008 07:45:52 -0700, "Shawn O. Pearce"
> <spearce@spearce.org> wrote:
>
>> Jakub Narebski <jnareb@gmail.com> wrote:
>> > This is partial summary of Git User's Survey 2008 [...]
>> >
>> > 03. With which programming languages are you proficient?
>> >
>> > Around 939 people answered this question.  C is most popular with 59%;
>> > Ruby and surprisingly a bit shell script programming have around second
>> > place, with about 52-53%.  More people are proficient with Python than
>> > in Perl by about 1/3-1/4.  Very few people (25 responses, around 3%)
>> > feel proficient in Tcl/Tk, which means shallow pool of possible git-gui
>> > and gitk contributors.
>
> Rewrite them in perl or python and get more patches?
> The fact that it is not perl withheld me from finding solutions to
> problems I still have with the git-gui gitk combination

Ruby!

-- 
Felipe Contreras

Re: Git User's Survey 2008 partial summary

[David Aguilar]

On Wed, Sep 3, 2008 at 9:25 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> On Wed, Sep 3, 2008 at 6:20 PM, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
>> On Wed, 3 Sep 2008 07:45:52 -0700, "Shawn O. Pearce"
>> <spearce@spearce.org> wrote:
>>
>>> Jakub Narebski <jnareb@gmail.com> wrote:
>>> > This is partial summary of Git User's Survey 2008 [...]
>>> >
>>> > 03. With which programming languages are you proficient?
>>> >
>>> > Around 939 people answered this question.  C is most popular with 59%;
>>> > Ruby and surprisingly a bit shell script programming have around second
>>> > place, with about 52-53%.  More people are proficient with Python than
>>> > in Perl by about 1/3-1/4.  Very few people (25 responses, around 3%)
>>> > feel proficient in Tcl/Tk, which means shallow pool of possible git-gui
>>> > and gitk contributors.
>>
>> Rewrite them in perl or python and get more patches?
>> The fact that it is not perl withheld me from finding solutions to
>> problems I still have with the git-gui gitk combination
>
> Ruby!
>
> --
> Felipe Contreras

There's already a python git-gui:
    http://cola.tuxfamily.org/

PyQt is a very mature library, which is one of the primary reasons I
chose Python.
Does Ruby have any good and mature UI libraries?  I know it's all the
rage for web stuff, but I haven't heard too much about people using it
for GUIs.

-- 
 David

Re: Git User's Survey 2008 partial summary, part 2

[Jakub Narebski]

This is partial summary of Git User's Survey 2008 after more that 1600 
(yes, that is more 1.6 _thousands_ responses) just after the 4 days
of running the survey.  It is based on "Analysis" page for this survey:
  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8
 
We have around 1606 individual responses (excluding 21 responses in the 
'testing' channel), as compared to 683 individual responses for 2007 
survey, and (I think) 115 answers (Base = 115) for 2006 survey. 
That is a lot, especially after so short time since staring the 
survey.


03. With which programming languages are you proficient?

Situation changed a bit since last announcement.  Nor Ruby with 59%
dominates a bit over C with 55%.  I guess this is caused by GitHub
crowd: announcement about this survey was posted on GitHub blog
(thanks defunkt!).
 
There are now 22 responses (around 1%) of "I am not a programmer".
This means that you don't need to be a programmer to use Git.

Popular (from what I have glanced) languages in the 'other' section
include Erlang, Lua, OCaml, Haskell, Objective-C; there is Scala, Vala, 
Smalltalk, R, ActionScript, Prolog, SQL, Forth, and even TeX/LaTeX 
mentioned; someone even wrote Brainfuck here. 


04. How did you hear about Git?

Here 'blog entry' and 'some project uses it' with 38% dominates over 
'Linux kernel news' and 'word of mouth' with 22-24%.

Among 'other' there is quite popular Google Tech Talk about Git by Linus 
Torvalds, available on YouTube (which admittedly probably should be as 
one of choices), LKML (Linix kernel mailing list) which probably some 
put as 'Linux kernel news' and some not, FLOSS podcast, GitHub, Ruby 
adopting Git.  Among more unique and interesting 'other' replies there 
is "Faculty Advisor at NSF REU" and "school Professor", "Ruby community 
just went apeshit all of a sudden" ;-) and "Ruby On Rails switching to 
git overnight"; some individual people line 'Randall Schwartz' or 
'Scott Chacon'.


08. Which Git version(s) are you using? (multiple choices)

Most people use current version of git: 70% use git 1.5.x, and 40% use 
git 1.6.x, and only 3 people use pre 1.3.x version.  Note that some
people use different versions on different machines, or on different 
operating systems, so the numbers do not add to 100%.

Around 8% (123 replies) use 'master' branch.  Sorry Junio, it looks like 
it wouldn't be easy to find/detect bugs as soon as they hit 'master', 
before releasing.  (Unfortunately this survey lack question to find how 
many people run *-rcN (release candidate) version, but it is very long 
as it is with 60 questions and 55 minutes average time of answering 
question, and anegdotical evidence (comments) of requiring around 15 
minutes to fill it without spending much time on free-form questions).


25. How do you publish/propagate your changes? (multiple choices)

Most people (92%) simply push to publishing public repository.  Second 
is 'pull request' with 32%; I guess this includes GitHub social thingy.
git-svn as form of publishing changes is third with 27%; thanks Eric 
Wong!  Format-patch + email is only fourth with 22%, but quite close to 
git-svn and pull-request.

For publishing to other SCMs (32 replies, 2% or responses) people use 
git-bzr, git-p4, git-cvsexportcommit, git-acu (AccuRev); some publish 
to Mercurial, ClearCase or Visual SourceSafe.


To be continued...

P.S. Which non free-form questions are you interested most, BTW?
-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary

[Jan Hudec]

On Wed, Sep 03, 2008 at 19:43:20 -0700, David Aguilar wrote:
> On Wed, Sep 3, 2008 at 9:25 AM, Felipe Contreras
> <felipe.contreras@gmail.com> wrote:
> > On Wed, Sep 3, 2008 at 6:20 PM, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
> >> On Wed, 3 Sep 2008 07:45:52 -0700, "Shawn O. Pearce"
> >> <spearce@spearce.org> wrote:
> >>
> >>> Jakub Narebski <jnareb@gmail.com> wrote:
> >>> > This is partial summary of Git User's Survey 2008 [...]
> >>> >
> >>> > 03. With which programming languages are you proficient?
> >>> >
> >>> > Around 939 people answered this question.  C is most popular with 59%;
> >>> > Ruby and surprisingly a bit shell script programming have around second
> >>> > place, with about 52-53%.  More people are proficient with Python than
> >>> > in Perl by about 1/3-1/4.  Very few people (25 responses, around 3%)
> >>> > feel proficient in Tcl/Tk, which means shallow pool of possible git-gui
> >>> > and gitk contributors.
> >>
> >> Rewrite them in perl or python and get more patches?
> >> The fact that it is not perl withheld me from finding solutions to
> >> problems I still have with the git-gui gitk combination
> >
> > Ruby!
> >
> > --
> > Felipe Contreras
> 
> There's already a python git-gui:
>     http://cola.tuxfamily.org/
> 
> PyQt is a very mature library, which is one of the primary reasons I
> chose Python.

Sorry, but I disagree. Tried PyQt, been hugely disapointed. Boils down to any
thing that can make Python (or, for that matter, any) interpreter segfault
being totally broken.

But as far as Qt goes, I would really just stick with C++. Python or Ruby
have some advantage, but I am not sure it's that big to offset the fact, that
a lot of code already exists in QGit.

> Does Ruby have any good and mature UI libraries?  I know it's all the
> rage for web stuff, but I haven't heard too much about people using it
> for GUIs.

Qt? I believe Ruby Qt bindings are in better shape (properly handle Qt
deleting objects under Ruby's hands).

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

Git User's Survey 2008 partial summary, part 3

[Jakub Narebski]

This is partial summary of Git User's Survey 2008 after more that 2000 
(yes, that is more than _two thousands_ responses) just after the 5 days
of running the survey.  It is based on "Analysis" page for this survey:
  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8

We have around 2040 individual responses (excluding 21 responses in the 
'testing' channel), as compared to 683 individual responses for 2007 
survey, and (I think) 115 answers (Base = 115) for 2006 survey. 
That is quite a lot, especially after only five days (or so) since 
staring the survey.
 

Getting started with Git:
~~~~~~~~~~~~~~~~~~~~~~~~~

05. Did you find Git easy to learn?

Replies look like nice gaussian-like distribution, centered around the 
middle, but with slight bias towards 'easy' part, with 16% hard vs 24% 
easy, and 2% very hard vs 6% very easy.

The 2% (33) for 'very hard' can be a bit of a concern...


09. How long do you use Git?

Majority of people use Git for about from 3 months to 1 year (29% for 
3-6 months, 26% for 6-12 months). The graph is centered around this 
values, too. Few people (58, 3%) said that they use Git more than two 
years, fewer still (41, 2%) stated that they use it from the very 
beginning.

This hopefully means that most people had contact with git after it had 
improved its UI.


10. Rate your own proficiency with Git

Here again the distribution is almost perfectly symmetric.  Most people 
say that they are proficient with Git enough for everyday use (44%), 
slightly more (23%) can offer advice than selected 'casual, needs 
advice', while slightly more (7%) thinks themself novices than people 
who think that know Git very well (4%).

For this survey it seems to imply that results would not be biased 
(scewed) by people who know Git well to very well.


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

154 says yes, 1674 says no, 227 skipped this question.

It is not just git developers that answer this question... which is kind 
of obvious because we do not have that many developers (I wish).


How do you use Git:
~~~~~~~~~~~~~~~~~~~

18. What operating system do you use Git on? (multiple answers)

This question was made multiple choices (one can use Git on different 
operating systems; either multi-boot, or multiple machines), as 
compared to free-form question in 2006 and 2007 survey.

Linux (or should we say GNU/Linux?) dominates with 82%, second is
MacOS X (Darwin) with 59%, and MS Windows is only third with 25%
(here msysGit is more popular with 15% than Cygwin with 10%).
If we consider fact that MS Windows dominates desktop, one can see that 
Git is not very popular choice for Windows machines, probably because 
of perceived and real shortcomings when trying to run it on non-POSIX 
operating system.  The domination of Linux is not strange considering 
fact that Git was created for the purpose of being distributed version 
control system for Linux kernel, and is designed around Linux features 
(fast fork, fast stat, prototyping using scripts, etc.).

Among 'other' operating systems there is iPhone, iPod, 
MS Windows/AndLinux,... but also for example Ubuntu or Debian Sarge,
which clearly should be marked as Linux instead.


19. What hardware platforms do you use Git on? (multiple answers)

Here slightly more people (88%) use 32-bit machines than 64-bit machines 
(61%)... if we can say that, as it is multiple choice question.  Few 
people chose 'portable/handheld' (51, 3%), fewer still selected 
'other' (8 replies). 

Here 'other' I think mean: I don't know which option to chose.  There is 
one OLPC-XO, but also PowerPC and PPC/G4.


20. What editor, IDE or RAD you use working with Git?

Currently Vim, with 48% or 841 responses, wins by narrow margin over 
TextMate which has 44% (782 responses).  Curious.

Emacs is third with 18%, followed closely by Eclipse with 13%.  More 
than 50 replies (responses) also have NetBeans IDE, XCode, MS Visual 
Studio and Notepad++.

Among 'other (please specify)' we have nano, Kate, Gedit, Geany, 
e-Editor (aka. TextMate for Windows) or just e, jEdit, SlickEdit, 
SharpDevelop, SciTE, Code::Blocks, joe, ActiveState Komodo, Aptana and 
a few others; even one 'ed' ;-)

Note that quite a few people wrote about integration with IDE/editor in 
the "35. What tools (or kind of tools) would you like to see Git 
support in?" question.

To be continued...

-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary

[David Aguilar]

On  0, Jan Hudec <bulb@ucw.cz> wrote:
> > 
> > There's already a python git-gui:
> >     http://cola.tuxfamily.org/
> > 
> > PyQt is a very mature library, which is one of the primary reasons I
> > chose Python.
> 
> Sorry, but I disagree. Tried PyQt, been hugely disapointed. Boils down to any
> thing that can make Python (or, for that matter, any) interpreter segfault
> being totally broken.


That's curious, I've never seen a single segfault.
You don't happen to run suse or fedora, do you?
I've not experienced your pains once on debian.


> But as far as Qt goes, I would really just stick with C++. Python or Ruby
> have some advantage, but I am not sure it's that big to offset the fact, that
> a lot of code already exists in QGit.

I have no comment here -- for me it boils down to the fact
that I end up writing much less code in Python vs. C++.  GUIs
are not performance critical.  Most of the time is spent in
the event loop waiting for user input.  Ditto for Ruby, tcltk,
etc --the benefit is in writing less code that does more.  I
sure as hell wouldn't write something performance critical in
those languages, but for something simple like a GUI it makes
perfect sense.

git-cola and qgit actually do different things.  qgit has
an awesome history viewer.  git-cola is primarily for doing
stuff like splitting apart changes into separate commits, etc.
I tend to work things up into a working state and then commit
things separately.  For example, there might be one commit
that does some refactoring and a second commit that uses the
refactored code, etc.  git-cola started out with emulating
git-gui's featureset though it has surpassed it now, which is
why its focus is on the commit workflow.


> > Does Ruby have any good and mature UI libraries?  I know it's all the
> > rage for web stuff, but I haven't heard too much about people using it
> > for GUIs.
> 
> Qt? I believe Ruby Qt bindings are in better shape (properly handle Qt
> deleting objects under Ruby's hands).

Right -- if you got segfaults due to object deletion it's
because you let things go out of scope.  I do not doubt that
the ruby bindings handle this better, but I have not ever
seen the problems you describe so I wouldn't know.
RubyQt looks interesting but the differences are superficial
given that I've not run into any problems.  As far as suckage
goes, ruby and python both suck equally so the choice is
immaterial ;)

Anyways, this is getting off topic for the git list so I'll
stop here.  If you have some pyqt examples that demonstrate
segfaults then I'm sure phil (pyqt author) would be happy
to see them, but those details are probably left off-list or
on the pyqt devel list. 

ciao,

-- 

	David

Re: Git User's Survey 2008 partial summary, part 3

[Shawn O. Pearce]

Jakub Narebski <jnareb@gmail.com> wrote:
> 
> Note that quite a few people wrote about integration with IDE/editor in 
> the "35. What tools (or kind of tools) would you like to see Git 
> support in?" question.

Both Eclipse and NetBeans are getting on board with JGit and trying
to make viable plugins from it.  So hopefully by the next survey
this particular question will have been answered for a decent
precentage of our IDE toting users.

Actually, I'm rather excited by what's going on in the Git IDE
space these days.  The NetBeans plugin is seeing more activity,
and since GSoC so has EGit.  Both projects have been steadily
picking up contributors.  Quite a good thing.

-- 
Shawn.

Re: Git User's Survey 2008 partial summary, part 3

[Andreas Ericsson]

Shawn O. Pearce wrote:
> Jakub Narebski <jnareb@gmail.com> wrote:
>> Note that quite a few people wrote about integration with IDE/editor in 
>> the "35. What tools (or kind of tools) would you like to see Git 
>> support in?" question.
> 
> Both Eclipse and NetBeans are getting on board with JGit and trying
> to make viable plugins from it.  So hopefully by the next survey
> this particular question will have been answered for a decent
> precentage of our IDE toting users.
> 
> Actually, I'm rather excited by what's going on in the Git IDE
> space these days.  The NetBeans plugin is seeing more activity,
> and since GSoC so has EGit.  Both projects have been steadily
> picking up contributors.  Quite a good thing.
> 

The geany ide has some limited git support as well. Since it's
written in C, I believe a libified git would boost its level of
support tremendously.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Git User's Survey 2008 partial summary, part 4 - how do we use Git

[Jakub Narebski]

This is partial summary of Git User's Survey 2008 after more that 2000 
(yes, that is more than _two thousands_ responses) just after the 6 days
of running the survey.  It is based on "Analysis" page for this survey:
  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8

Please think of ways to examine this data, and about conclusions that we 
can draw from those statistics.



27 & 28. How often do you use the following forms of git commands or
         extra git tools? (Matrix - One answer per row)
       + never / rarely / sometimes / often

First, even though those questions looks a bit terryfying on first
glance, with this large matrix of commands, most people (around 3/4)
filled those two questions: 1562 responses with 540 skipped for 27.,
and 1454 total and 648 skipped for its continuation, question 28.

This large matrix had the additional advantage of teaching newcomers
to git about some rarer or newer git commands or versions of git
commands.

Below there is very simple statistics based on individual columns,
without taking into consideration any correlation between columns, or
any relation. For example it doesn't take into account that for some
'often' is somene's else 'sometimes'.


Top 10 often used commands

===================================
Command + options      | often [%]
-----------------------------------
git push               | 72% (1120)
git add + git commit   | 65% (1012)
git commit -a          | 63%  (981)
git pull (no remote)   | 44%  (682)
git pull <remote>      | 37%  (578)
git commit <file>...   | 34%  (528)
git merge              | 31%  (482)
gitk                   | 28%  (404)
git rebase             | 25%  (365)
git stash              | 22%  (320)
...................................
git remote update      |   6%  (92)

Analysis: strangely "git add + git commit" is slightly more used than
"git commit -a"; I would suspect that "git commit -a" would dominate a
bit over other forms of committing.  What is for me more suprising is
that "git commit <file>..." has such large presence in often used
commands; I would think that it should be mostly used as 'sometimes'
command.

Pity there was no "git pull . <branch>" to compare if people swith to
newer "git merge <branch>" for merging local branches.


Top 10 sometimes used commands

===================================
Command + options      | sometimes
-----------------------------------
git merge              | 28% (443)
git pull <remote>      | 27% (429)
git stash              | 26% (380)
git remote             | 26% (379)
git revert             | 24% (346)
git rebase             | 23% (332)
gitk                   | 23% (328)
git fetch [<options>]  | 21% (331)
git commit --amend     | 20% (314)
git commit <file>...   | 20% (311)

Analysis: "git commit --amend" and "git commit <file>" are here. That
is understandable, and for me expected.


Top 10 rarely used commands

===================================
Command + options      | rarely [%]
-----------------------------------
git revert             | 31% (454)
git pull <URL> <ref>   | 22% (348)
git blame              | 21% (328)
git fetch [<options>]  | 20% (313)
git rebase             | 20% (291)
git remote             | 20% (289)
git merge              | 18% (286)
git apply              | 18% (284)
git pull --rebase      | 18% (283)

Analysis: "git pull <URL> <ref>", direct pull without using
remote-tracking branches, is quite popular among rarely used
commands.  Strange that "git pull ---rebase" is among rarely
used; I would think it is question of workflow... but perhaps
rarely encountered workflow.

Notice that "git blame" is more 'rare' than gitk, which is in top 10
of both 'often' and 'sometimes' table. I guess that this is caused by
the fact that git has other, often better, ways to examine and browse
history.


Top 12 never used (or not well known) commands

==========================================================
Command + options       never    rarely  sometime   often
----------------------------------------------------------
git relink             1217-84%   37- 3%    6- 0%    1- 0%
git cvsserver          1255-80%   23- 1%    8- 1%    3- 0%
git imap-send          1245-80%   35- 2%    6- 0%    2- 0%
git cvsexportcommit    1227-79%   26- 2%   16- 1%   12- 1%
git citool             1191-76%   51- 3%   15- 1%   17- 1%
git bundle             1184-76%   80- 5%   22- 1%    8- 1%
git request-pull       1110-76%  105- 7%   32- 2%   16- 1%
git instaweb           1142-73%   97- 6%   31- 2%    8- 1%
git ... --dirstat      1141-73%   93- 6%   39- 2%    8- 1%
git am -i              1129-72%  130- 8%   48- 3%    8- 1%
git blame -L           1123-72%  103- 7%   50- 3%   11- 1%
git daemon (pushing)   1110-71%   99- 6%   38- 2%   36- 2%

It is sorted by percentage; note that commands from different
questions might have higher percentage even though lower number of
replies: it is caused by the fact that number of replies (non skipped
responses) is different.

Analysis: Nobody is I think suprised by the commands that appear in
this table...



29. Which of the following features do or did you use? 
30. Which features do you find unique and/or useful ones,
    compared to other systems (other SCMs)?
    (Choice - Multiple answers)

There were 1387 responses / 715 skipped for question 29., and
there were 1190 responses / 912 skipped for question 30.

These two questions were a bit related, but first deals with the
features one uses (even if they are not unique to Git, or very
interesting), while second deals with which features one think to be
useful (even if one doesn't use them).

The 'use' columns conatin percentage of replies for question 29.,
while 'think' column is about question 30.

==================================================
Feature description                     use  think
--------------------------------------------------
gitk or other history viewer            72%   ---
stash                                   56%   63%
the index                               ---   44%
shell completion of commands            42%   ---
add --interactive
  or other partial commit helper        35%   38%
git-gui or other commit tool            31%   ---
interactive rebase                      31%   39%
submodules (subprojects)                30%   25%
bisect                                  28%   37%
my own scripts / scriptability          25%   28%
git-aware shell prompt                  23%   ---
integration with IDE/editor             20%   ---
working with dirty tree                 18%   14%
mergetool                               17%   13%
reflog                                  16%   16%
detaching HEAD                          14%    9%
non-default hooks / hooks system        11%   19%
shallow clone                            9%    6%
eol conversion (crlf)                    8%    6%
separate worktree                        7%   11%
git-filter-branch                        7%    7%
alternates mechanism                     6%    7%
gitattributes                            6%    4%
patch management interface               5%   ---
git bundle (off-line transport)          5%   10%
multiple worktrees (git-new-worktree)    3%   ---
commit templates                         2%    3%

About items which are missing in one of columns: either it is a broad
concept so it is hard to say that one can "use" such feature, or
feature is not unique enough, or is not part of git... or I forgot to
add it to second part.

Analysis: most popular is using history viewer (such as gitk, qgit,
giggle, GitNub, git-cola, etc.); stash even though it is quite new
feature also is very popular.  For me a bit strange is that partial
commits has more users than graphical commit tools like
git-gui/git-citool.  Most (well, 44%) think that the index is unique
and/or useful feature.  Biggest difference in number of replies
between 29. and 30. question belongs, from what I see, to bisect.


31. If you use some important Git features not mentioned above, what
    are those? (Open ended text - Essay)

Total respondents: 115, skipped this question: 1987.

This I guess mean that we were exhaustive in our list of features,
as it doesn't seem to be many omissions...

-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary, part 4 - how do we use Git

[Andreas Ericsson]

Jakub Narebski wrote:
> 
> Analysis: strangely "git add + git commit" is slightly more used than
> "git commit -a"; I would suspect that "git commit -a" would dominate a
> bit over other forms of committing.

I believe people have finally gotten to grasp with the index. Besides,
those answers are probably a bit skewed, as people that use git as just
a faster and better cvs/svn aren't likely to be those who answer the
survey.

>  What is for me more suprising is
> that "git commit <file>..." has such large presence in often used
> commands; I would think that it should be mostly used as 'sometimes'
> command.
> 

I know myself and most others where I work use it as a 'fixup' command.
One commit is done, the second is being staged (git add or git add -i),
while testing reveals some silly bug in one of the files from the last
commit. Assuming that file isn't touched again, it's easy to fix up
using "git commit --amend <file>", as that automatically sets up a new
index so that the staged changes remain staged.

The alternative would be to do a mixed reset, git add <file>, git commit
--amend. Not so sexy.

> 
> Top 10 rarely used commands
> 
> ===================================
> Command + options      | rarely [%]
> -----------------------------------
> git revert             | 31% (454)
> git pull <URL> <ref>   | 22% (348)
> git blame              | 21% (328)
> git fetch [<options>]  | 20% (313)
> git rebase             | 20% (291)
> git remote             | 20% (289)
> git merge              | 18% (286)
> git apply              | 18% (284)
> git pull --rebase      | 18% (283)
> 
> Analysis: "git pull <URL> <ref>", direct pull without using
> remote-tracking branches, is quite popular among rarely used
> commands.  Strange that "git pull ---rebase" is among rarely
> used; I would think it is question of workflow... but perhaps
> rarely encountered workflow.
> 

Perhaps many who use it don't know that they are. The "git sync"
alias is much in use where I work. It's basically just a
"git pull --rebase && git push". As it was suggested on the mailing
list and also listed in some tutorial somewhere (don't know where),
I can imagine quite a lot of people using it without realising it.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Git User's Survey 2008 partial summary, part 4 - how do we use Git

[Jakub Narebski]

Andreas Ericsson wrote:
> Jakub Narebski wrote:
>> 
>> Analysis: strangely "git add + git commit" is slightly more used than
>> "git commit -a"; I would suspect that "git commit -a" would dominate a
>> bit over other forms of committing.
> 
> I believe people have finally gotten to grasp with the index. Besides,
> those answers are probably a bit skewed, as people that use git as just
> a faster and better cvs/svn aren't likely to be those who answer the
> survey.


From "Git User's Survey 2008 partial summary, part 3" subthread:
Message-Id: <200809060422.34779.jnareb@gmail.com>

>> 10. Rate your own proficiency with Git
>>
>> Here again the distribution is almost perfectly symmetric.  Most
>> people say that they are proficient with Git enough for everyday use
>> (44%), slightly more (23%) can offer advice than selected 'casual,
>> needs advice', while slightly more (7%) thinks themself novices than
>> people who think that know Git very well (4%).
>>
>> For this survey it seems to imply that results would not be biased
>> (skewed) by people who know Git well to very well.

So it doesn't seem that answers are skewed much...

-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary, part 3

[Jonas Fonseca]

On Sat, Sep 6, 2008 at 07:15, Shawn O. Pearce <spearce@spearce.org> wrote:
> Actually, I'm rather excited by what's going on in the Git IDE
> space these days.  The NetBeans plugin is seeing more activity,
> and since GSoC so has EGit.  Both projects have been steadily
> picking up contributors.  Quite a good thing.

One thing that I am wondering about is how to best integrate the
various git-specific traits. NetBeans already has several VCS plugins,
many of which are derived from the same code and have been built to
abide to the same UI design principles, and so naturally they have a
similar "feel" to them. It seems foolish to not try and respect this
when integrating git into the IDE space. Especially, to make it easier
for people to try out and switch to git.

One example is the question of how to enable users to work with the
index without adding too many obscure UI elements. NetBeans VCS
infrastructure and diff engine automatically annotates, which lines in
the editor has been changed, modified, or deleted, and allows users to
revert on a chunk level. While it seems very practical to extend the
annotation bar to allow changes to be staged (I am not sure if this is
even possible) it could end up cluttering a concept that many users
are already very familiar with.

I am curious what kind of considerations you have done on this topic
in your work on EGit.

-- 
Jonas Fonseca

Re: Git User's Survey 2008 partial summary, part 3

[Shawn O. Pearce]

Jonas Fonseca <jonas.fonseca@gmail.com> wrote:
> One thing that I am wondering about is how to best integrate the
> various git-specific traits. NetBeans already has several VCS plugins,
> many of which are derived from the same code and have been built to
> abide to the same UI design principles, and so naturally they have a
> similar "feel" to them. It seems foolish to not try and respect this
> when integrating git into the IDE space. Especially, to make it easier
> for people to try out and switch to git.

Yea, that's a big concern for any IDE implementor.  Many of the
Eclipse team providers (if not all of them?) have derived from the
CVS team provider that comes as part of the base platform.  So they
often share the same look-and-feel.  But I think Eclipse defines
less of a common VCS UI than what you are implying NetBeans does.

In Eclipse I think it is more common to define VCS custom views
(little windows/toolbars) and let the user turn on/off each view
as they see fit.
 
> One example is the question of how to enable users to work with the
> index without adding too many obscure UI elements. NetBeans VCS
> infrastructure and diff engine automatically annotates, which lines in
> the editor has been changed, modified, or deleted, and allows users to
> revert on a chunk level. While it seems very practical to extend the
> annotation bar to allow changes to be staged (I am not sure if this is
> even possible) it could end up cluttering a concept that many users
> are already very familiar with.

Yea, extending the annotation bar to show the index may actually
be useful quite useful.  If its only 15 pixels of horizontal width
lost that's actually worthwhile.  I think an older version of EGit
had something like this until I broke it.  I can't remember.

> I am curious what kind of considerations you have done on this topic
> in your work on EGit.

We've mostly ignored it.  I haven't put a lot of thought into it
because I have been focused on getting a solid JGit implementation
in place.

I do know that I really miss having an overview of what is
essentially the left side of git-gui; the staged and unstaged
(but modified) file lists.  The resource decorator is nice, but it
doesn't quite give the same flat-tree overview.

-- 
Shawn.

Git User's Survey 2008 partial summary, part 5 - other SCM

[Jakub Narebski]

This is partial summary of Git User's Survey 2008 for the state from
Sep 09, 2008, with almost 2300 responses (yes, _thousands_ responses).
It is based on "Analysis" page for this survey:
  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8

We have around 2295 individual responses (excluding 21 responses in the 
'testing' channel), for the time I got those data, as compared to
683 individual responses for 2007 survey, and (I think)
115 answers (Base = 115) for 2006 survey.  That is a lot,...
I wonder how many replies we would have at the end of survey, Oct 10?


---
Below I concentrated on questions related to other SCM, although not all
those questions were from "Other SCM" section.

12) What other SCM did or do you use?
    (Matrix - One answer per row)

The table below is sorted alphabetically, with exception of 'custom'
and 'other' which are put at the end.

==============================================================
SCM                    |  Never     | Used it    | Still use
--------------------------------------------------------------
AccuRev                | 60% (1227) |  0%    (6) |  0%    (1)
Arch (or clone)        | 54% (1108) |  7%  (136) |  0%    (1) 11
Bazaar-NG              | 47%  (969) | 12%  (257) |  4%   (76) 7
BitKeeper              | 55% (1135) |  5%  (111) |  0%    (3) 12
ClearCase              | 53% (1101) |  7%  (151) |  2%   (37) 10
CVS                    | 12%  (242) | 62% (1277) | 13%  (260) 1 
Darcs                  | 48%  (990) | 13%  (262) |  2%   (48) 6
Mercurial              | 40%  (819) | 18%  (379) |  8%  (174) 5
Monotone               | 55% (1136) |  5%   (95) |  1%   (16) 14
MS SourceSafe          | 46%  (949) | 19%  (401) |  1%   (20) 3
MS Studio Team System  | 57% (1173) |  3%   (56) |  0%    (9)
Perforce               | 51% (1045) |  9%  (191) |  3%   (64) 9
PVCS                   | 56% (1157) |  5%  (100) |  0%    (3) 13'
RCS                    | 43%  (881) | 19%  (389) |  3%   (59) 4
SCCS                   | 56% (1146) |  5%  (100) |  0%    (7) 13'
Subversion             |  3%   (59) | 35%  (726) | 59% (1217) 2
SVK                    | 51% (1043) | 11%  (226) |  1%   (15) 8
..............................................................
custom (non-published) | 54% (1115) |  4%   (90) |  1%   (22) 
other                  | 51% (1042) |  5%   (98) |  1%   (22) 
--------------------------------------------------------------
Total respondents      |                2060
skipped this question  |                 235

Side note: each of version control systems have at least one
respondent which still use it.  That was not assured.


Top 5 "still use", which should mean version control system which
are used beside, and together with Git.

=====================================
SCM                    | still use
-------------------------------------
1.  Subversion         |  59% (1217)
2.  CVS                |  13%  (260)
3.  Mercurial          |   8%  (174)
4.  Bazaar-NG          |   4%   (76)
5.  Perforce           |   3%   (64)
.....................................
7.  Darcs              |   2%   (48)
10. Monotone           |   1%   (16)

Note that 10th place for Monotone excludes 'custom' and 'other';
otherwise it would be 12th.

Analysis: Subversion (SVN) is most popular, eclipsing all other SCMs.
This might be caused by the fact that git-svn is very good in
integrating Subversion with Git enhances and emphasizes popularity of
Subversion.  CVS, at time very popular, leaves the field to Subversion
(advertised as replacement fo CVS, as "CVS done right") and other
systems.  This agrees with the number of people which have above
version control systems in Ohloh software stack [need new analysis for
final version; for now you can use data from GitSurvey2007 page at git
wiki], and with Debian Popularity Contest (popcon) [here also new data
is needed].

A bit suprising for me is high place of Perforce.  Another strange
thing (and a bit alarming) is that MS Visual SourceSafe has higher
place than Monotone; but that might be caused by different design and
different target groups of Monotone and Git, which might have caused
that the communities have almost no overlap; people choose either Git
or Monotone, one or the other.  BitKeeper has also a very low number
of active users among Git users... but that is not that strange,
considering history.

See also "Adoption of various VCSes" blog post by Newren:
http://blogs.gnome.org/newren/2007/11/17/adoption-of-various-vcses/
which is less than year old.  This essay includes proprietary SCMs
like Perforce.


Top 5 "used it" (assumption: no longer in use) version control
systems.  Replaced by Git or other SCM, tried and abandoned, etc.

=====================================
SCM                    | used it
-------------------------------------
1.  CVS                |  62% (1277)
2.  Subversion         |  35%  (726)
3.  MS SourceSafe      |  19%  (401)
4.  RCS                |  19%  (389)
5.  Mercurial          |  18%  (379)
.....................................
6.  Darcs              |  13%  (262)
7.  Bazaar-NG          |  12%  (257)
14. Monotone           |   5%   (95)

Note that again 'other' and 'custom' are excluded.

Analysis: We can see here former glory of CVS, which was once standard
for version control system.  Its predecessor, single-file locking
version control system, RCS is also visible.

A bit suprising is 3rd place of MS Visual SourceSafe; I really hope
that it is either "I took a look at it and ran away", or "I had to use
it but fortunately no longer". And what do you think about this?


13) Why did you choose/use Git? (if you use Git) 
    What do you like about using Git? 
    (Open ended text - Essay)

Total respondents       1723
skipped this question   572

14) Why did you choose/use other SCMs? (if you use other SCMs) 
    What do you like about using other SCMs? 
    (Open ended text - Essay)

Total respondents       1329
skipped this question   966


25) How do you publish/propagate your changes? 
    (Choice - Multiple answers)

======================================
method                  | using it                
--------------------------------------
push                    | 91%  (1740)
pull request            | 29%   (551)
format-patch + email    | 22%   (414)
git bundle              |  2%    (39)
......................................
git-svn                 |  26%  (498)
other foreign SCM^[*]   |   2%   (45)
......................................
other                   |   2%   (32)
======================================
Total respondents       |       1904
skipped this question   |        391

Footnote:
=========
[*] publishing to other foreing SCM:
  + Bazaar,      using git-bzr
  + CVS,         using git-cvsexportcommit
                 using git-cvs (probably git-cvsserver)
  + ClearCase,   using custom scripts
                 unspecified method
  + Perforce,    using git-p4
                 using git-p4-import
                 using patch
  + Mercurial,   using fast-import (?)
                 using email + hg mq
  + AccuRev,     using git-acu
  + Quilt,       using email
  + SourceSafe,  using shared workdir
                 using custom scripts
  + Subversion,  using shared workdir (?)
  + SVK,         using shared workdir
  + RCS,         using custom scripts
  + TeamWare,    using git-tw (unpublished yet)


Analysis, as pertinent to "other SCM" question: as you can see git-svn
is very popular, just below pull request (which probably include
GitHub social interface), and slightly higher (!) than format-patch
plus email, i.e. patch-based workflow.


26) If the way you publish your changes is not mentioned above,
    how do you publish your changes? Please explain. 
    (Open ended text - Essay)

Total respondents         95
skipped this question   2200

Here are listed only methods which are truly not mentioned above
(for example publishing to other SCMs usually doesn't count).
I have also tried to remove duplicated entries:
 * git-bzr allows for bidirectional syncing with a git
   repository. Useful when a project is hosted in Bazaar.
 * Standard diff file encompassing all changes for a specific feature.
 * On one machine, I use rsync to push my repository upstream by hand
   (for HTTP access).
 * Personal use only (many responses).
 * we also use a script that uses various git=diff concoctions to
   generate patch bundles
 * format-patch + lighthouse;
   We create patches and attach to tickets in Lighthouse
   (lighthouseapp.com) for several open-source projects.
 * Patches on reviewboard
 * format-patch and attach to bugtracking system
 * Just so I can be a little more specific about how I publish. I
   primarily use stgit and then put the patches in an issue tracker
   (like trac).
 * I do format-patch. Then I've written a script that posts to
   pastebin.com My friend uses another script that downloads from
   pastebin.com ;)
   NOTE: why don't use gist.github.com, or even just GitHub...
 * forum or IRC to the project owners
 * format-patch and uploading to a webserver.
 * format-patch + save patch on wiki page
 * "git diff > my.patch" and upload to the drupal.org issue queue.
 * after-push hooks on github to campfire/lighthouse/twitter
 * GTP (Git Torrent Protocol -- my own implementation)
 * git archive
 * gitweb's snapshot/tarball plugin
 * Since my hosting provider is temperamental, I have many projects in
   a strange hierarchy, and I want to recreate my repository
   precisely, I just tar up my master folder and upload that.
 * Because of a retarded network setup out of my control, I use a
   disgusting script based on git clone --bare, tar, scp, ssh, and
   rsyncing.
 * Sometimes as simple and stupid as tarball / scp
 * Transport of entire repositories via CD/DVD.
   NOTE: wouldn't it be easier to use USB stick and bundles?
 * copy the whole changed file or tell them what to change since some
   windows people do not know what a patch is or how to apply it :-/
 * I use git for a repo with lots of huge files (RAW image files). git
   pull/push insists on packing up objects but I'd rather have one
   object per file in .git/objects, so I rsync those and then pull the
   changeset history via std means.
 * For all my projects, I set up a post-update hook on my dreamhost
   account to force update. I use a standard remote named "stage".
 * Package a RubyGem and upload it to the files area of the relevant
   RubyForge project, and make sure the same RubyGem is in my Git repo
   so GitHub will generate a gem as well.
 * Custom scripts for pull requests and patchbombing

An interesting comment:
 * At work I use git for tracking one project I work on. It is a
   project with Unix line endings in some files, and Windows file
   endings in the other. My company uses VSS which cannot handle Unix
   line endings and otherwise is not very powerful. So I use git to
   track my history, but use VSS as backup repository. Also I git pull
   my git repository to a backup repository on a network drive.

An explanation of choices:
 * There are cases where I will push to continuous integration
   repositories to get a specific tree tested. Otherwise it is all
   about pulling.
 * I do not publish my changes. Other people can access a copy of my
   code, but I do not use a git repository on a server. I do not
   understand that concept good enough (hint: that needs docs for
   total dummies)
 * I only use git for cloning/pulling repo's for now, since it is too
   hard to use. I don't have a lot of spare time to learn it since svn
   is easy and useful. I would use it if there was a doc that explains
   it to us svn people.

And there is also:
 * For 27 and 28, there is no "I don't know< I'm using the GUI's",
   so I'm not ticking the answers
 * I don't know!
 * GitHub; Gitosis; Capistrano
 * Send them to somebody who has git access.
   NOTE: probably format-patch + email
 * can some one provide free private git service?
   ANSWER: There are many free _public_ git service, and a few
   non-free git services offer private repositories (e.g. GitHub)

 * Carrier pigeon


Analysis: as you can see format-patch + <something>, where <something>
is not email or mailing list, but issue tracker, wiki, patch queue or
other web site/web application is quite popular.  

Some people use different combinations of tar/zip and scp or other
transport, or rsync, or ssh to simply transfer the whole repository
(some of which might be migitated by using bundles instead, but only
if there is access to shell account on remote site and there is git on
remote site to "unpack" bundle).  Sometimes it is caused by the lack
of decent features in a web server, sometimes it is lack of knowledge.


15) Do you miss features in git that you know from other SCMs? 
    If yes, what features are these (and from which SCM)? 
    (Open ended text - Essay)

Total respondents       1046 (some/many of them wrote 'no')
skipped this question   1249

This is just a very quick summary, based on a first few pages of
responses, Full analysis is I think best left for after closing the
survey, because I think this would be a lot of work...

So here is preliminary list, or rather beginning of one:
 * sparse/partial checkout and clone (e.g. Perforce)
 * better MS Windows support (CVS, Mercurial, Darcs, Bazaar)
 * integration with IDE/RAD/editor/filemanager
 * good GUI/visual tools/graphical shell (on multiple platforms)
 * 'soft' locking aka. watching files (like in ClearCase)
 * equivalent of 'hg serve': fast web interface and pull-server
   in one (Mercurial)
 * better documentation (svnbook, hgbook, generic)
 * traversing history of individual file (unknown SCM)
 * better interface for staging individual changes
   (Darcs interface is better than 'git add -i')
 * better UI for submodules (less commands to issue, like in Subversion)
 * integrated conflict resolution tool
 * tracking empty repositories (Bazaar)
 + It would be helpful to have something like "comments" in monotone.
 + hackability and portability of Mercurial
 + good Unicode support, the current implicit handling sucks
 + Hg had less commands to do the same :) (Mercurial)
 + big file support (ClearCase) 
 + maybe a 'info' style command where it lists all branches, tags,
   remotes and repo specific config. Rather than using separate
   commands.
 + I don't miss any *feature* from SVN, but I do miss some of the
   terse commands. Reverting my local changes to a file in Git always
   feels like hard work, and in SVN it's a dead simple command, etc.
 + svn:externals from subversion (especially the part where one can do
   partial imports from other repositories) something in the likes of
   hgforest, i.e. having 'live' submodules which are not fixed to a
   specific revision (from Mercurial)

 * better support for tracking third party tools like 'piston'
   for Subversion.
   NOTE: there is 'braid', formerly 'giston' for git
 * mainly fine-grained commit support (staging diff hunks),
   branch management, stashing
   NOTE: all of this is available in modern Git
 * easier to use commit identifiers. "It's hard to memorize the
   seemingly random commit hash (even the short 7-character ones)."


Note that people used this question to put feature requests, instead
_only_ things from other SCMs that they are missing in Git; and even
when they did correctly, they forgot often to state _which_ SCM is
given feature from.

-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Anatol Pomozov]

Hi,
> A bit suprising for me is high place of Perforce.
Some huge companies use Perforce. A good example here is Google. But
at the same time there are a lot of Google employees who interested in
git. Especially after Linus TechTalk. Googlers created a wrapper for
perforce that tries to bring git to everyone and ~300 people actively
use it.
--
anatol

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Jeff King]

On Thu, Sep 11, 2008 at 10:14:17PM +0200, Jakub Narebski wrote:

> SCM                    |  Never     | Used it    | Still use
> --------------------------------------------------------------
[...]
> CVS                    | 12%  (242) | 62% (1277) | 13%  (260) 1 

I like to think of this as 1017 monitors that we have saved from getting
punched in frustration.

> 25) How do you publish/propagate your changes? 
>     (Choice - Multiple answers)
> 
> ======================================
> method                  | using it                
> --------------------------------------
> push                    | 91%  (1740)

Obviously a quite popular choice. I wonder if this could be broken down
more in next year's survey:

  - push into my public repo, interested people pull
  - push into central repo

-Peff

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Jakub Narebski]

Joshua Jensen wrote:
> Anatol Pomozov wrote:
>> Jakub Narebski wrote:
>>>
>>> A bit suprising for me is high place of Perforce.
>>>     
>> Some huge companies use Perforce. A good example here is Google. But
>> at the same time there are a lot of Google employees who interested in
>> git. Especially after Linus TechTalk. Googlers created a wrapper for
>> perforce that tries to bring git to everyone and ~300 people actively
>> use it.
>>
> Many game companies use Perforce, as it has pretty good handling of 
> gigabytes upon gigabytes of art content.  This is one area where a 
> centralized repository trumps the distributed ones with full history.  
> The checkout tree for one product I worked on was 70 gigabytes, and I 
> still mapped out a large number of files.  You can imagine how that 
> becomes too unwieldy to have all history locally.

Dana How (Cc-ed) worked on better support in Git for very large and
not well compressed files (and usually with short history).  Her
solution was to add support to git to limit size of blobs which
entered packs (files/blobs of size larger than given limit were
left as loose objects), and share those loose objects using network
filesystem.  You can search git mailing list to find exact details
of this. IIRC mentioned patches were not accepted; instead there was
proposed a solution where problematic blobs of very large files were
packed into separate kept pack, and this kept pack (or packs, each
containing single blob) were shared using some network filesystem
(network drive).


In addition to that in Documentation/RelNotes-1.5.3 we have:

  - "pack-objects" honors "delta" attribute set in
    .gitattributes.  It does not attempt to deltify blobs that
    come from paths with delta attribute set to false.

(but as far as I can see this attribute is otherwise undocumented).
This can also help performance for a repository with very large files.

-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[david]

On Thu, 11 Sep 2008, Jakub Narebski wrote:

> A bit suprising for me is high place of Perforce.  Another strange
> thing (and a bit alarming) is that MS Visual SourceSafe has higher
> place than Monotone; but that might be caused by different design and
> different target groups of Monotone and Git, which might have caused
> that the communities have almost no overlap; people choose either Git
> or Monotone, one or the other.  BitKeeper has also a very low number
> of active users among Git users... but that is not that strange,
> considering history.

I think you are making the wrong assumption here.

someone may use CVS becouse they contribute to a project that is only 
availabe via CVS

someone may use Perforce becouse that is the VCS that their company uses

if you do commercial development with windows you are almsot going to be 
required to use MS VSS.

you are looking at it from the point of view of 'which VCS would you 
select for a new project', but that would be a very different question.

I find it interesting that the number of people who use git and the other 
DVCS systems in so small. Is this becouse the 'market share' of those 
other systems is small? or becouse people who learn git aren't willing to 
put up with other systems (or vice-versa)? or is there some other trend 
or tendancy that makes people who select one DVCS more likely to work on 
similar projects, so people interested in those types of projects will 
generally just see a single DVCS system

David Lang

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Jakub Narebski]

On Fri, 12 Sep 2008 00:51, david@lang.hm wrote:
> On Thu, 11 Sep 2008, Jakub Narebski wrote:
> 
> > A bit suprising for me is high place of Perforce.  Another strange
> > thing (and a bit alarming) is that MS Visual SourceSafe has higher
> > place than Monotone; but that might be caused by different design and
> > different target groups of Monotone and Git, which might have caused
> > that the communities have almost no overlap; people choose either Git
> > or Monotone, one or the other.  BitKeeper has also a very low number
> > of active users among Git users... but that is not that strange,
> > considering history.
> 
> I think you are making the wrong assumption here.
> 
> Someone may use CVS becouse they contribute to a project that is only 
> availabe via CVS
> 
> Someone may use Perforce becouse that is the VCS that their company uses

True, I have forgot that "I use this SCM" (or "I used this SCM") doesn't
necessarily mean that one _choose_ this SCM.  One can use some SCM
because it is SCM project uses, or because their company requires it;
but not necessary, as git-svn and git-p4 show one can use Git, and
make it interact with respectively Subversion and Perforce, and trying
to make it look like one uses this other SCM.

> If you do commercial development with Windows you are almsot going to be 
> required to use MS VSS.

I hope not.  Even Microsoft themselves supposedly doesn't recommend
Source(Un)Safe, but MS Visual Studio Team System.

> You are looking at it from the point of view of 'which VCS would you 
> select for a new project', but that would be a very different question.

Right.

> I find it interesting that the number of people who use git and the other 
> DVCS systems in so small. Is this becouse the 'market share' of those 
> other systems is small? Or becouse people who learn git aren't willing to 
> put up with other systems (or vice-versa)? Or is there some other trend 
> or tendancy that makes people who select one DVCS more likely to work on 
> similar projects, so people interested in those types of projects will 
> generally just see a single DVCS system

I don't think 59% (in the example case of using currently Subversion)
is small.  Take into account for example that there are people who (as
seen from responses to other questions in this survey) use SCM (Git)
only to track their private work, never publishing.  Then there are
people who do not track (perhaps with exception of web interfaces)
other projects development using version control systems, even if they
do follow their development.

Side note: the number of replies in "still use" category agrees with
other data, like mentioned Ohloh stacks, or Debian popcon (package
popularity), or Newren research, or vcscomparison research.

-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[dhruva]

Hello,



----- Original Message ----
> From: Jakub Narebski <jnareb@gmail.com>
> To: David Lang <david@lang.hm>
> Cc: git@vger.kernel.org
> Sent: Friday, 12 September, 2008 4:14:58 PM
> Subject: Re: Git User's Survey 2008 partial summary, part 5 - other SCM
> 
> On Fri, 12 Sep 2008 00:51, david@lang.hm wrote:
> > On Thu, 11 Sep 2008, Jakub Narebski wrote:
> > 
> > > A bit suprising for me is high place of Perforce.  Another strange
> > > thing (and a bit alarming) is that MS Visual SourceSafe has higher
> > > place than Monotone; but that might be caused by different design and
> > > different target groups of Monotone and Git, which might have caused
> > > that the communities have almost no overlap; people choose either Git
> > > or Monotone, one or the other.  BitKeeper has also a very low number
> > > of active users among Git users... but that is not that strange,
> > > considering history.
> > 
> > I think you are making the wrong assumption here.
> > 
> > Someone may use CVS becouse they contribute to a project that is only 
> > availabe via CVS
> > 
> > Someone may use Perforce becouse that is the VCS that their company uses

I am in that situation...

> True, I have forgot that "I use this SCM" (or "I used this SCM") doesn't
> necessarily mean that one _choose_ this SCM.  One can use some SCM
> because it is SCM project uses, or because their company requires it;
> but not necessary, as git-svn and git-p4 show one can use Git, and
> make it interact with respectively Subversion and Perforce, and trying
> to make it look like one uses this other SCM.

Since we cannot change management to decide on using git instead of whatever they are using overnight. Best is to have tools like git-p4/git-svn which allows interoperability. Once people gain confidence, they can replace that whatever SCM with git. That is the path I am planning at my place of work.

-dhruva



      Get an email ID as yourname@ymail.com or yourname@rocketmail.com. Click here http://in.promos.yahoo.com/address

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[david]

On Fri, 12 Sep 2008, Jakub Narebski wrote:

> On Fri, 12 Sep 2008 00:51, david@lang.hm wrote:
>> On Thu, 11 Sep 2008, Jakub Narebski wrote:
>>
> True, I have forgot that "I use this SCM" (or "I used this SCM") doesn't
> necessarily mean that one _choose_ this SCM.  One can use some SCM
> because it is SCM project uses, or because their company requires it;
> but not necessary, as git-svn and git-p4 show one can use Git, and
> make it interact with respectively Subversion and Perforce, and trying
> to make it look like one uses this other SCM.

I would expect people to still count those as using the other SCM. git-svn 
and git-p4 can do a lot, but they don't do everything, once in a while I 
would expect to need to use the native commands for the upstream SCM

>> I find it interesting that the number of people who use git and the other
>> DVCS systems in so small. Is this becouse the 'market share' of those
>> other systems is small? Or becouse people who learn git aren't willing to
>> put up with other systems (or vice-versa)? Or is there some other trend
>> or tendancy that makes people who select one DVCS more likely to work on
>> similar projects, so people interested in those types of projects will
>> generally just see a single DVCS system
>
> I don't think 59% (in the example case of using currently Subversion)
> is small.  Take into account for example that there are people who (as
> seen from responses to other questions in this survey) use SCM (Git)
> only to track their private work, never publishing.  Then there are
> people who do not track (perhaps with exception of web interfaces)
> other projects development using version control systems, even if they
> do follow their development.

Subversion is not a Distributed SCM. I am pointing out the much smaller 
overlap between distributed SCM systems.

David Lang

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Jakub Narebski]

On Sat, 13 Sep 2008, David Lang wrote:
> On Fri, 12 Sep 2008, Jakub Narebski wrote:
>> On Fri, 12 Sep 2008 00:51, david@lang.hm wrote:
>>> On Thu, 11 Sep 2008, Jakub Narebski wrote:
>>>
>> True, I have forgot that "I use this SCM" (or "I used this SCM") doesn't
>> necessarily mean that one _choose_ this SCM.  One can use some SCM
>> because it is SCM project uses, or because their company requires it;
>> but not necessary, as git-svn and git-p4 show one can use Git, and
>> make it interact with respectively Subversion and Perforce, and trying
>> to make it look like one uses this other SCM.
> 
> I would expect people to still count those as using the other SCM. git-svn 
> and git-p4 can do a lot, but they don't do everything, once in a while I 
> would expect to need to use the native commands for the upstream SCM

Well, you can check it by analysing correlations between answers. 
Unfortunately there is no way to share raw data beside me generating it
and sending, or you registering at Survs.com and me adding you as admin,
but you can emulate it using existing (just created) filters on
"Analyze" page for Git User's Survey 2008:
  http://www.survs.com/shareResults?survey=M3PIVU72&rndm=OKJQ45LAG8
  http://tinyurl.com/GitSurvey2008Analyze

For example if you chose filter 'publish to git-svn', which select all
replies that have answered question 25.: how do you publish and checked
git-svn option, you can see that among those responders 6 of 555 (1%)
selected that they _never_ used Subversion.

>>> I find it interesting that the number of people who use git and the other
>>> DVCS systems in so small. Is this becouse the 'market share' of those
>>> other systems is small? Or becouse people who learn git aren't willing to
>>> put up with other systems (or vice-versa)? Or is there some other trend
>>> or tendancy that makes people who select one DVCS more likely to work on
>>> similar projects, so people interested in those types of projects will
>>> generally just see a single DVCS system
>>
>> I don't think 59% (in the example case of using currently Subversion)
>> is small.  Take into account for example that there are people who (as
>> seen from responses to other questions in this survey) use SCM (Git)
>> only to track their private work, never publishing.  Then there are
>> people who do not track (perhaps with exception of web interfaces)
>> other projects development using version control systems, even if they
>> do follow their development.
> 
> Subversion is not a Distributed SCM. I am pointing out the much smaller 
> overlap between distributed SCM systems.

Oh, now I understand and agree with what you noticed: in "I use" most
you get for distributed SCM is 9%, most in "used it" is 19% (hmmm...
is it really small?).

First, from various nonscientific researches (Ohloh stack count, Debian
popcon, counting well-known projects using given SCM; Google search
trends do not count) it looks like Git has biggest market share from
distributed version control systems (Subversion has larger share, but
it is centralized).  So one would expect at most
  <share of SCM>/<share of Git>*100% 
as a percentage for sum of "I used it" and "I use it" columns, or at
least for "I use it" answer.

Second, one usually choose single SCM for his/her projects. And one
usually interacts (for example tracks) projects which use the same SCM;
kernel folks use Git (and kernel-related projects migrate to Git too,
take for example ALSA project), people who work more on Windows (Mozilla)
and have product competing with Linux (OpenSolaris) ;-) use Mercurial,
Ruby and RoR people moved to Git, Ubuntu / Canonical use Bazaar-NG.

Third different SCM have slightly different UI, and different underlying
models.  If you use one, usually you find other SCM concept and commands
unintuitive (and of course vice versa).

But that is just speculation...
-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Nguyen Thai Ngoc Duy]

On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
>  15) Do you miss features in git that you know from other SCMs?
>     If yes, what features are these (and from which SCM)?
>     (Open ended text - Essay)
>
>  Total respondents       1046 (some/many of them wrote 'no')
>  skipped this question   1249
>
>  This is just a very quick summary, based on a first few pages of
>  responses, Full analysis is I think best left for after closing the
>  survey, because I think this would be a lot of work...
>
>  So here is preliminary list, or rather beginning of one:
>   * sparse/partial checkout and clone (e.g. Perforce)

Have not read the survey result, but do you recall what is the most
used term for sparse/partial checkout? What SCMs do sparse/partial
checkout? I think it could be usable as it is now in my
will-be-sent-again series, but I don't really know how people want it
to from that.
-- 
Duy

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Jakub Narebski]

On Sun, 14 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
> >
> >  15) Do you miss features in git that you know from other SCMs?
> >     If yes, what features are these (and from which SCM)?
> >     (Open ended text - Essay)
> >
> >  Total respondents       1046 (some/many of them wrote 'no')
> >  skipped this question   1249
> >
> >  This is just a very quick summary, based on a first few pages of
> >  responses, Full analysis is I think best left for after closing the
> >  survey, because I think this would be a lot of work...
> >
> >  So here is preliminary list, or rather beginning of one:
> >   * sparse/partial checkout and clone (e.g. Perforce)
> 
> Have not read the survey result, but do you recall what is the most
> used term for sparse/partial checkout? What SCMs do sparse/partial
> checkout? I think it could be usable as it is now in my
> will-be-sent-again series, but I don't really know how people want it
> to from that.

Well, I do not remember, and I think I haven't got original data now,
only the above summary.  Besides, I haven't even began analysing data
from question 34. about ideas for features, and I guess we would see
'partial checkou' ide there too.

>From short discussion on #git channel, Abhijit Menon-Sen (crab) said
that they are 'restricted views' in Perforce, but this terminology is
completly alien to Git.  Bjorn Steinbrink (doener_) mentioned that
Subversion 1.5 acquired something they call 'sparse directories':

  http://blogs.open.collab.net/svn/2007/06/sparse-director.html

(Sidenote: perhaps it would be worth to follow SVN UI for sparse 
checkout here?).  In short, people on #git agreed that 'partial 
checkout' is a good name; I think that 'sparse checkout' better renders 
idea that one can checkout _set_ of files and directories, and it is 
not only limited to single subdirectory ('subtree checkout' / 
'subdirectory checkout') or a single file.

Comparison table on Better SCM Initiative

  http://better-scm.berlios.de/comparison/comparison.html

names it "Ability to Work only on One Directory of the Repository" and 
uses '"work_on_dir"' id.

HTH
-- 
Jakub Narebski
Poland

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[david]

On Sun, 14 Sep 2008, Nguyen Thai Ngoc Duy wrote:

> On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>  15) Do you miss features in git that you know from other SCMs?
>>     If yes, what features are these (and from which SCM)?
>>     (Open ended text - Essay)
>>
>>  Total respondents       1046 (some/many of them wrote 'no')
>>  skipped this question   1249
>>
>>  This is just a very quick summary, based on a first few pages of
>>  responses, Full analysis is I think best left for after closing the
>>  survey, because I think this would be a lot of work...
>>
>>  So here is preliminary list, or rather beginning of one:
>>   * sparse/partial checkout and clone (e.g. Perforce)
>
> Have not read the survey result, but do you recall what is the most
> used term for sparse/partial checkout? What SCMs do sparse/partial
> checkout? I think it could be usable as it is now in my
> will-be-sent-again series, but I don't really know how people want it
> to from that.

the most common use-case is people who want to follow a project but (at 
least think that they) don't need the history. so they want to save 
time/bandwideth/disk space by not downloading things they don't need.

David Lang

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Andreas Ericsson]

david@lang.hm wrote:
> On Sun, 14 Sep 2008, Nguyen Thai Ngoc Duy wrote:
> 
>> On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>  15) Do you miss features in git that you know from other SCMs?
>>>     If yes, what features are these (and from which SCM)?
>>>     (Open ended text - Essay)
>>>
>>>  Total respondents       1046 (some/many of them wrote 'no')
>>>  skipped this question   1249
>>>
>>>  This is just a very quick summary, based on a first few pages of
>>>  responses, Full analysis is I think best left for after closing the
>>>  survey, because I think this would be a lot of work...
>>>
>>>  So here is preliminary list, or rather beginning of one:
>>>   * sparse/partial checkout and clone (e.g. Perforce)
>>
>> Have not read the survey result, but do you recall what is the most
>> used term for sparse/partial checkout? What SCMs do sparse/partial
>> checkout? I think it could be usable as it is now in my
>> will-be-sent-again series, but I don't really know how people want it
>> to from that.
> 
> the most common use-case is people who want to follow a project but (at 
> least think that they) don't need the history. so they want to save 
> time/bandwideth/disk space by not downloading things they don't need.
> 

I disagree, and this would be a thin or shallow checkout to me (although
I realize the nomenclature is unfortunately similar here). What I've
heard is normally documentation writers that don't want to be able to
even accidentally modify any code, so they just want Documentation/
subdirectory. Shallow clones are already supported (albeit with a lot
of limitations).

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Mark Brown]

On Fri, Sep 12, 2008 at 12:44:58PM +0200, Jakub Narebski wrote:
> On Fri, 12 Sep 2008 00:51, david@lang.hm wrote:

> > If you do commercial development with Windows you are almsot going to be 
> > required to use MS VSS.

> I hope not.  Even Microsoft themselves supposedly doesn't recommend
> Source(Un)Safe, but MS Visual Studio Team System.

Yes, it's strongly deprecated by Microsoft these days and has some known
limitations that aren't going to be addressed.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."

Re: Git User's Survey 2008 partial summary, part 5 - other SCM

[Jakub Narebski]

On Mon, 15 Sep 2008, David Lang <david@lang.hm> napisał:
> On Sun, 14 Sep 2008, Nguyen Thai Ngoc Duy wrote:
>> On 9/12/08, Jakub Narebski <jnareb@gmail.com> wrote:
>>>  15) Do you miss features in git that you know from other SCMs?
>>>     If yes, what features are these (and from which SCM)?
>>>     (Open ended text - Essay)
>>>
>>>  Total respondents       1046 (some/many of them wrote 'no')
>>>  skipped this question   1249
>>>
>>>  This is just a very quick summary, based on a first few pages of
>>>  responses, Full analysis is I think best left for after closing the
>>>  survey, because I think this would be a lot of work...
>>>
>>>  So here is preliminary list, or rather beginning of one:
>>>   * sparse/partial checkout and clone (e.g. Perforce)
>>
>> Have not read the survey result, but do you recall what is the most
>> used term for sparse/partial checkout? What SCMs do sparse/partial
>> checkout? I think it could be usable as it is now in my
>> will-be-sent-again series, but I don't really know how people want it
>> to from that.
> 
> the most common use-case is people who want to follow a project but
> (at least think that they) don't need the history. so they want to
> save time/bandwideth/disk space by not downloading things they don't
> need. 

Errr... the idea is to implement partial (sparse, narrow) _checkout_,
which is doable, not partial/lazy _clone_, which is very, very 
difficult.

Partial checkout *might* help reduce disk space because usually 
repository database (which is compressed and deltaified) is smaller 
than checkout; and if it isn't you can always use _shallow_ clone (only 
part of history) and/or remote alternates (with reference repository
not on your quota, or on different filesystem).  And it might help
checkout/commit/diff/status times (performance) on slow filesystems, 
with extremely large number of files in full checkout.  But contrary to
centralized SCM, where server is usually net away from working area,
partial checkout doesn't affect network usage _at all_.

-- 
Jakub Narebski
Poland