* Git User's Survey 2007 unfinished summary (long)
From: Jakub Narebski @ 2007-10-04 9:12 UTC (permalink / raw)
To: git
This is partial summary of Git User's Survey 2007,
ending at state from 28 September 2007.
The survey can be found here:
http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9
http://tinyurl.com/26774s
----
There were 683 individual responses
About you
~~~~~~~~~
01. What country are you in?
Answer | Count
------------------------------------------
Algeria | 1
Argentina | 3
Australia | 25
Austria | 9
Belgium | 5
Brazil | 20
Bulgaria | 1
Canada | 44
Chile | 2
China | 4
Colombia | 2
Czech Republic | 10
Denmark | 7
Ecuador | 1
Estonia | 1
European Union | 1
Finland | 23
France | 36
Germany | 64
Greece | 3
Hungary | 2
India | 13
Ireland | 2
Israel | 6
Italy | 14
Japan | 4
Jersey | 1
Latvia | 1
Malaysia | 1
Mexico | 1
Netherlands | 15
New Zealand | 5
Norway | 14
Philippines | 3
Poland | 6
Portugal | 2
Puerto Rico | 1
Romania | 1
Russian Federation | 6
Samoa | 1
Serbia | 1
Singapore | 2
Slovak Republic | 1
Slovenia | 2
South Africa | 4
Spain | 11
Sri Lanka | 1
Sweden | 14
Switzerland | 15
UK / US | 1
United Kingdom | 40
United States of America | 218
Venezuela | 1
Vietnam | 1
------------------------------------------
Base | 673 / 683
Total (sum) | 673
England and Scotland counts as United Kingdom here.
Table is sorted in alphabetical order.
As one can easily see, slightly less than third of GIT users
are in the USA (those who answered this survey).
02. What is your preferred non-programming language?
This is multiple answers question, although most people
gave only one preferred language.
Answer | Count
------------------------------------------
Afrikaans | 1
Bulgarian | 1
Castellano | 2
Catalan | 1
Chinese | 2
Czech | 10
Danish | 6
Dutch | 12
English | 416
Finnish | 16
French | 33
Galician | 1
German | 58
Greek | 2
Hebrew | 1
HibernoEnglish | 1
Hungarian | 3
Italian | 9
Japanese | 1
LSF (French sign language) | 1
Norwegian | 4
Polish | 5
Portuguese | 11
Romanian | 1
Russian | 13
Serbian | 1
Slovenian | 2
Spanish | 13
Swedish | 13
Swiss | 1
Ukrainian | 1
Vietnamese | 1
------------------------------------------
invalid (computer language) | 37
not understood | 4
------------------------------------------
Base | 662 / 683
Total (sum) | 684
The question itself is not well formulated, as one can see from the
number of answers with computer language, and "not understood"
answers. I am not native English speaker, but there were suggestions
to use "natural language" instead of "non-programming language".
Around two third of git users prefer English language, at least for
dealing with computers.
03. How old are you?
Answer | Count
------------------------------------------
< 18 | 11
18-21 | 75
22-25 | 174
26-30 | 203
31-40 | 146
41-50 | 45
51-75 | 13
76+ | 0
------------------------------------------
Base | 667 / 683
Total (sum) | 667
Youngest git user who answered this survey is 14 years old,
oldest is 74 years old. This is quite a span, I'd say, The age of 25
got most count (51 answers).
04. Which programming languages you are proficient with?
Answer | Count
------------------------------------------
C | 582
shell | 449
Perl | 244
Python | 316
Tcl/Tk | 26
------------------------------------------
Base | 648 / 683
Total (sum) | 1617
The choices include programming languages used by git. This is
multiple choice question (you can be proficient in more than one
programming language).
It look like there is only around 3/4 people proficient in Perl as
compared to Python; it looks like Python is more popular. C is most
popular; shell is more popular than Perl or Python. The fewest people
are proficient in Tcl/Tk. I'm sorry, git-gui and gitk guys; it looks
like not many developers... around 4% of git users.
Getting started with GIT
~~~~~~~~~~~~~~~~~~~~~~~~
05. How did you hear about GIT?
Answer | Count
------------------------------------------
LKML | 109
LWN (Linux Weekly News) | 39
KernelTrap | 15
KernelTraffic | 1
kernel.org | 9
freedesktop.org | 5
Linus presentation at Google | 48
Slashdot | 28
blog | 19
community site[*1*] | 12
news site | 34
searching Internet[*2*] | 6
other SCM / SCM research[*3*] | 20
Internet | 32
IRC | 6
Linux kernel uses it | 73
some project uses git | 47
developer by name[*4*] | 21
friend | 39
word of mouth | 15
work / coworker | 22
initial GIT announcement | 12
BitKeeper news | 24
------------------------------------------
don't remember | 13
other / uncategorized | 44
------------------------------------------
Base | 658 / 683
Total (sum) | 693
[*1*] Community site are sites like Digg, Reddit and "planet" sites.
[*2*] This includes answer of "Google"
[*3*] This includes some other SCM mailing list, VCS comparison,
and searching for an SCM.
[*4*] Linus Torvalds, Carl Worth, Keith Packard, Randal Schwartz,...
This was free-form question, and tabularizing answers was quite a work.
It is taken as multiple choice question (for example link to Linus
presentation at Google found at Slashdot).
Other / uncategorized includes for example GoogleTalk IM, 3 answers
IIRC.
Note that Linus Torvalds presentation at Google / YouTube got it's
own category, and generated quite a bit of git users.
06. Did you find GIT easy to learn?
Answer | Count
------------------------------------------
very easy | 38
easy | 136
reasonably | 318
hard | 131
very hard | 33
------------------------------------------
Base | 656 / 683
Total (sum) | 656
Nice gaussian curve. Most users find it reasonably easy to use.
On the other hand git is not considered easy...
07. What helped you most in learning to use it?
TO DO
646 / 683 non-empty responses
08. What did you find hardest?
TO DO
596 / 683 non-empty responses
09. When did you start using git? From which version?
Answer | Count
------------------------------------------
(no version string) | 165
0.99x | 26
0.x | 12
1.0x | 31
1.1x | 9
1.2x | 12
1.3x | 22
1.4x | 147
1.5x | 198
------------------------------------------
Base | 626 / 683
Total (sum) | 626
NOTE! This table shows _only_ answers in which there was given git
version explicitely. Some people gave date, some people wrote how long
they have used git. Those answers needs also processing; they are
skipped here.
It looks like the git users community is divided into part of users
who started using it from beginning, or almost from beginning, and
users which started using git post v1.3.0 (post e.g. making separate
remotes the default layout of branches).
Other SCMs
~~~~~~~~~~
10. What other SCMs did/do you use?
This question is not well thought, as it gathers together (in the
free-form which is not easy to tabularize with large number of
responses we got) SCMs which one used and no longer uses, SCMs which
are used in parallel with git, and SCMs which are used instead of git
(which are chosen as main SCM for a project). Nevertheless it shows
with which VCS, and its conceps, are users familiar with.
Answer | Count
------------------------------------------
AccuRev | 3
Aegis | 1
Bazaar | 19
Bazaar-NG | 50
BitKeeper | 27
CCC | 1
CMS (Digital) | 1
CMS (VAX) | 1
CMS (VMS) | 1
CVCS | 1
CVS | 454
ClearCase | 43
CodeMgr | 1
Continuus | 1
Darcs | 78
DesignSync | 1
GNU Arch | 57
Mercurial | 92
Monotone | 31
Omniworks | 1
OpenCM | 1
PRCS | 1
PVCS | 12
Perforce | 50
Quilt | 2
RCS | 61
SCCS | 18
SCM | 1
SCSS | 1
SVK | 19
Serena Version Manager | 1
SourceForge | 1
Sourcerer's Apprentice | 1
StarTeam | 4
Subversion | 524
Sun NSE | 2
Sun TeamWare | 4
VCS | 1
VMS | 1
VSS | 26
'cp -a' | 1
akpm patch scripts | 1
custom in-house tools | 1
diff patch | 2
none | 9
notes-on-paper-made-by-hand | 1
really horrible stuff | 1
scripts for 'shadow trees' | 1
tarballs | 1
tlib | 1
undisclosed | 1
------------------------------------------
Base | 654 / 683
Total (sum) | 1615
The above table is in alphabetical order. It was generated from
free-form answers, tabularized as multiple choice answer.
Note that this question does not distinguish between SCMs/VCSs which
were used prior to Git and used no longer, SCMs which are used beside
(in parallel) to Git perhaps interacting with Git, and SCMs which are
used instead of Git. Also note that this is _Git User's_ survey, so it
those number for example do not represent number of e.g. users of
Mercurial as compared to e.g. users of Subversion.
Below there is table of SCM used, sorted by the number of responses.
Note that annotations (like "a little CVS") were not weighted here.
Only SCMs which has count more that 10 are shown. One person can (and
usually did) chose more than one SCM.
Answer | Count
------------------------------------------
Subversion | 524
CVS | 454
Mercurial | 92
Darcs | 78
RCS | 61
GNU Arch | 57
Bazaar-NG | 50
Perforce | 50
ClearCase | 43
Monotone | 31
BitKeeper | 27
VSS (MS Visual SourceSafe) | 26
Bazaar | 19
SVK | 19
SCCS | 18
PVCS | 12
tla+baz+bzr | 129
------------------------------------------
Base | 654 / 683
As you can see two most popular SCMs are Subversion ('svn') and CVS,
with Subversion being a bit more popular. Among distributed SCMs
with most count are Mercurial ('hg') and Arch and its descendants
('tla', 'baz', 'bzr'). From proprietary (non-OSS) revision control
systems Perforce ('p4'), ClearCase (and ClearCase UCM), BitKeeper ('bk')
and Visual SourceSafe (aka. that awful M$ one ;-) got most count.
Note that the count for given version control system does not reflect
_preferences_ of git users. One can be forced to use specified SCM.
See also question 35: "How does GIT compare to other SCM?".
11. Why did you choose GIT?
TO DO
643 / 683 non-empty responses
12. Why did you choose other SCMs?
TO DO
606 / 683 non-empty responses
13. What would you require from GIT to enable you to change,
if you use other SCM for your project?
TO DO
474 / 683 non-empty responses
14. Did you import your repository from foreign SCM? What SCM?
Answer | Count
------------------------------------------
N/A | 15
No | 169
Yes | 372
------------------------------------------
Base | 556 / 683
Total (sum) | 556
This is anly partial analysis, as it deals only with first part of
question (which, because of second part, has free-form structure and
needed processing).
One can see that around half of git users have imported (at least one
project) from foreign SCM.
15. What tool did you use for import?
Answer | Count
------------------------------------------
by hand | 7
custom script | 21
fast-import script | 3
Tailor | 28
-------------------------------------------
git-cvsimport | 81
parsecvs | 12
fromcvs | 2
cvs2git | 1
cvstogit | 1
git-svn | 150
git-svnimport | 66
git-archimport | 15
bk2git (customized) | 1
darcs2git | 4
git-p4 | 4
git-p4import | 1
git-ucmimport | 1
hg-to-git | 2
hg2git | 2
hgpullsvn | 1
hgsvn | 1
moin2git | 1
------------------------------------------
unspecified | 18
N/A | 114
------------------------------------------
Base | 467 / 683
Total (sum) | 538
16. Do your GIT repository interact with other SCM? Which SCM?
Answer | Count
------------------------------------------
N/A | 35
No | 228
Yes | 228
------------------------------------------
Base | 491 / 683
Total (sum) | 491
This is anly partial analysis, as it deals only with first part of
question (which, because of second part, has free-form structure and
needed processing).
One can see that around third of git users interacts (for at least one
project) with foreign SCM, as compared to half of git users which have
imported other SCM.
17. What tool did/do you use to interact?
Answer | Count
------------------------------------------
by hand | 10
custom script | 16
Tailor | 4
convert-repo | 1
fromcvs | 1
git-cvsexportcommit | 8
git-cvsimport | 19
git-cvsserver | 2
git-svn | 164
git-svnimport | 2
git-p4 | 4
git-p4import | 1
-----------------------------------------
unspecified | 2
N/A | 153
------------------------------------------
Base | 385 / 683
Total (sum) | 388
The only tool which really allows to interact (two-way) with other SCM
is git-svn (164 / 232).
How you use GIT
~~~~~~~~~~~~~~~
18. Do you use GIT for work, unpaid projects, or both?
Answer | Count
------------------------------------------
work | 56
unpaid projects | 212
both | 377
work + both | 433
------------------------------------------
Base | 645 / 683
Total (sum) | 645
Around two third of people use git at work, or for work.
See also question 55: "Would commerical (paid) support from a support
vendor be of interest to you/your organization?"
19. How do you obtain GIT?
Answer | Count
------------------------------------------
binary package | 283
source tarball | 210
pull from main repository | 153
------------------------------------------
Base | 646 / 683
Total (sum) | 646
Around half more people use binary packages than source tarball (or
source package, I think). More than half of people compile its own git
(pull is also followed by compilation).
In earlier partial survey summary, from 27-08-2004 (a month earlier)
there were twice as many people installing git from binary packages.
20. What hardware platforms do you use GIT on?
(on Unices: result of "uname -i")
Note: 'uname -i' does not work on all Unices. I'm sorry for this
mistake.
Answer | Count
------------------------------------------
Intel | 73
Athlon | 2
i386 | 171
i586 | 9
i686 | 60
IA-32 | 6
IA-64 | 8
AMD | 35
amd64 | 48
x86 | 156
x86-64 | 112
Apple | 8
iMac | 1
MacBook | 7
PowerBook | 10
PPC | 52
ppc64 | 7
ARM | 6
Alpha | 2
PA-RISC | 1
parisc64 | 1
MIPS | 1
mips64 | 1
mipsel | 2
SPARC | 8
sparc64 | 6
SUNW | 6
Sun-Fire | 4
sun4u | 3
sun4v | 1
k8 | 1
------------------------------------------
unknown | 67
------------------------------------------
Base | 637 / 683
Total (sum) | 875
The above table is in some arbitrary order. It was generated from
free-form answers, tabularized as multiple choice answer, as one
person can use git on more than one architecture.
Those results probably needs further processing to reduce number of
choices, by gathering architectures.
"Unknown" usually means that something else instead of architecture
was given (like operating system), or architecture was too generic,
like "PC".
21. What OS (please include the version) do you use GIT on?
Answer | Count
------------------------------------------
AIX | 1
FreeBSD | 16
OpenBSD | 3
HP-UX | 1
Linux | 582
MS Windows (Cygwin) | 22
MS Windows (msys) | 1
MS Windows (unsp.) | 35
MacOS X / Darwin | 94
Solaris | 11
SunOS | 5
UNIX (unsp.) | 1
too many to list | 1
------------------------------------------
MS Windows (together) | 58
FreeBSD / OpenBSD | 19
Unices (together) | 19
------------------------------------------
Base | 645 / 683
Total (sum) | 775
The above was generated from free-form answers, tabularized as
multiple choice answer, as one person can use git on more than one
operating system.
This is only rough analysis, because it does not include operating
system version, or for Linux distribution(s) used.
22. What projects do you track (or download) using GIT (or git web interface)?
TO TABULARIZE
560 / 683 non-empty responses
23. How many people do you collaborate with using GIT?
TO TABULARIZE
575 / 683 non-empty responses
What ranges should be used here: 1, 2-9, 10-99, 100-999, 1000+ or
perhaps 1, 2-5, 6-15, 16-25, 26-50, 50-100, 100-1000, 1000+, or yet
another?
24. How big are the repositories that you work on?
TO DO
525 / 683 non-empty responses
Some git repositories have more than 50k files, more than 150k
commits, more than 100mb largest file (although not single directory
has all those).
25. How many different projects do you manage using GIT?
TO TABULARIZE
577 / 683 non-empty responses
26. Which porcelains do you use?
Multiple answers (one can use more than one porcelain).
Answer (multiple choice) | Count
------------------------------------------
core-git | 558
cogito (deprecated) | 56
Patch management interface: : 57
...........................................
StGIT | 41
Guilt (formerly gq) | 13
pg (deprecated) | 3
own scripts | 95
other | 14
------------------------------------------
Base | 593 / 683
Total (sum) | 780
Those 14 "other" answers make me wish to have provided "if other,
what it was?" (sub)question; actually not only for this question.
It is understandable that Cogito still has some users, even though it is
deprecated, and [I think] all of its functionality can be found in
git-core porcelain. It was meant as SCM / porcelain layer when git-core
didn't have it and consisted almost only of plumbing commands.
Quite a bit of people use patch management interface: StGIT, Guilt,
even deprecated and abandoned pg (Patchy Git). StGIT has more users
than Guilt (formerly gq), although that might be caused by the fact
that StGIT was here longer... Some say that it is because of Guilt
having non-standalone documentation; it needs reading hgbook, as Guilt
concepts are based on mq (Mercurial [patch] queues) extension.
Large number of users use their own scripts, more than any
non-standard porcelain. One wonders if this is a result of good
git scriptability.
14 users choose other... and there is no "what other" question,
unfortunately...
If you are reading this: what were those other porcelains?
27. Which git GUI do you use?
Multiple answers (one can use more than one GUI). Note that for the
first week and a bit of survey "CLI" answer had no explanation that it
means command line interface, so results might be bit skewed.
Answer (multiple choice) | Count
------------------------------------------
CLI (command line) | 398
gitk | 347
git-gui | 123
qgit | 82
gitview | 15
giggle | 48
tig | 41
instaweb | 16
(h)gct | 3
qct | 3
KGit | 6
git.el | 31
other | 15
giggle + gitview | 63
------------------------------------------
Base | 572 / 683
Total (sum) | 1128
As one can see almost as many people use gitk as CLI. Most used GUI
are gitk and git-gui, most probably because they are distributed with
git, and because they are portable. QGit is also quite popular,
although GTK+ viewers, namely giggle and gitview are also quite
popular (note that there might be instances of users using both giggle
and gitview). I am a bit suprised about popularity of Giggle, I'd say.
Tig (text-mode interface for git) and git.el (GIT mode for Emacs) are
also quite popular.
I wonder what are those 15 other GUI. Why oh why there were no "What
is this 'other GUI'?" question.
28. Which (main) git web interface do you use for your projects?
Answer | Count
------------------------------------------
gitweb | 382
cgit | 7
wit (Ruby) | 5
git-php | 1
other | 27
------------------------------------------
Base | 422 / 683
Total (sum) | 422
Around two third (closer to 4/7) of git users use some kind of web
interface for their projects.
Most use gitweb (which is distributed with git), 7 use cgit, 5 wit
(Ruby), most probably projects sharing site with XMMS2, 1 git-php
(I wonder who...), and there are 27 "other" answers, which I am most
curious about. What are they?
Some answered "other" as "N/A" (meaning they do not use web interface)
instead, what it is not obvious, not answering this question. The
explanation that this is possible was added later during duration of
survey.
29. How do you publish/propagate your changes?
Multiple choices, as one can use different methods for different
projects, for example pushing to public repo for a project maintained,
and sending patches via email to participate in third person project
development.
Answer | Count
------------------------------------------
push | 456
pull | 220
format-patch + email | 172
pull request | 65
bundle | 13
other | 70
------------------------------------------
Base | 589 / 683
Total (sum) | 996
Here "other" means just not listed workflow, although it would be also
interesting to know details.
Most popular is push, I guess to public "publishing" repository
(and/or probably to mirror repositories). It is twice as popular
as next method, gathering more than 3/4 of users.
Pull was supposed to mean logging to public server and pulling
changes from private repo, not pulling someone other changes.
It is second most popular method.
Sending patches via email is two to three times as popular
as sending pull request.
30. Does git.git repository include code produced by you?
Answer | Count
------------------------------------------
Yes | 99
No | 512
------------------------------------------
Base | 611 / 683
Total (sum) | 611
As it can be seen, only (or perhaps it is that many?) around
a 6th to 7th of git users participate in its development by
providing code.
Internationalization
~~~~~~~~~~~~~~~~~~~~
31. Is translating GIT required for wider adoption?
Answer | Count
------------------------------------------
Yes | 49
No | 383
Somewhat | 158
------------------------------------------
Base | 590 / 683
Total (sum) | 590
More than half of responders doesn't think that translating GIT
is required for wider adoption.
32. What do you need translated?
TO TABULARIZE
172 / 683 non-empty responses
33. For what language do you need translation for?
In alphabetic order, free-form question, treated as multiple choice.
Answer | Count
------------------------------------------
Afrikaans | 1
Belorussian | 1
Chinese | 5
Dutch | 2
English[*1*] | 3
Filipino | 1
Finnish | 3
French | 21
German | 17
Greek | 1
Hebrew | 1
Hindi | 1
Hungarian | 1
Italian | 4
Japanese | 5
Mandarin | 1
Norwegian | 2
Polish | 2
Portuguese | 6
Russian | 6
Serbian | 2
Slovenian | 1
Spanish | 9
Swedish | 2
Tagalog | 1
Ukrainian | 1
------------------------------------------
Base | 143 / 683
Total (sum) [*2*] | 100
[*1*] Git messages and documentation _is_ in English
[*2*] Some answers were: "do not translate".
German and French are most popular. Spanish, Portuguese, Russian,
Chinese + Mandarin and Japanese have count 5 or more.
What you think of GIT
~~~~~~~~~~~~~~~~~~~~~
34. Overall, how happy are you with GIT?
Answer | Count
------------------------------------------
unhappy | 13
not so happy | 36
happy | 179
very happy | 302
completely ecstatic | 112
------------------------------------------
Base | 642 / 683
Total (sum) | 642
Nice, git users are mostly very happy with git.
13 grumpy users, hmmm...
35. How does GIT compare to other SCM tools you have used?
Answer | Count
------------------------------------------
Better | 505
Equal (comparable) | 96
Worse | 30
N/A | 52
------------------------------------------
Base | 631 / 683
Total (sum) | 631
Clearly Git is superior SCM! (In the minds of Git users at least) ;-)
Seriously, one should take into consideration that those results are
biased, because it is _Git User's_ Survey, and people usually choose
SCM because they think it is best choice.
No answer (null answer) might mean that responder does not use and did
not use other SCMs to compare, or at least think that he/she does not
have sufficient basis for a comparison.
NOTE: I have to check if number of non-empty responses is calculated
properly. I think it is, but I will make sure.
36. What do you like about using GIT?
TO DO
578 / 683 non-empty responses
No full analysis yet, and no count of answers, but it seems that the
following are encountered most often (or at least those I remember
best):
* clean design
* performance (speed)
* size of repository
* reliability, robustness, data integrity
* flexibility, scriptable
* command set, features (git-bisect)
* history rewriting (amend, rebase, interactive rebase, reset)
* history viewers, searching and browsing history
* distributed nature, offline work, full history locally,
"local commits"
* easy and in-place branching
* easy merging, includes renames detection
* push/pull via ssh, pull via plain http -- no server needed
* easy to install: few dependencies, portable, lightweight
37. What would you most like to see improved about GIT?
(features, bugs, plug-ins, documentation, ...)
TO DO
512 / 683 non-empty responses
So many suggestions...
First, some of suggestions are actually implemented already, for
example git development Changelog (present in the form of RelNotes),
shallow clone support, submodules support. This means that new
features are not very well announced (which was one of comments here,
too).
Some of features and improvements mentioned:
* generic behavior:
- less chatter, clean distinction between success or fail
(it it was about git-pull, it is addressed already)
- better, more verbose error messages, with link to documentation
- diagnostic output in case of problems;
something like git-explain / git-state
- more universal undo / continue
- command line consistency, option consistency: getopt / gitopt
* documentation:
- unified, organized, searchable documentation
- The Git Book (c.f. cvs/svn/hgbook);
tutorial leading to advanced concepts like rebase, filter-branch,
grafts, submodules, gitattributes
- Git Cookbook / Git Recipies;
best practices document, usage scenarios, workflows used, HOWTO
- Git for Dummies (for people who haven't used SCM at all)
- more hooks and hook examples
- mid-level (script / plugin writer leve) docs
- git1line docs a la sed1line.txt
- "git <cmd> --help" returning one page of short command summary,
not manpage; "git help --all --summary" for all command with
oneline description
* other SCMs:
- cogito migration guide / tutorial (!)
- other SCM to git (concept, commands) cheat sheet
- git-bzr (and other SCMs) two-way integration
- git-svnserve: git functioning as Subversion server
* git-svn:
- automatic handling svn:externals using submodules and vice versa
- svnmerge and svk merge markers tracking/marking of merges
* more --interactive:
- git add --interactive in git-gui: allow to divide hunks
- git rebase -interactive: graphical interactive rebase in git-gui
- ncurses-based remote editing
* tools:
- better Emacs support; Vim plugin; IDE plugins (Eclipse, KDevelop,
IntelliJ IDEA,...)
- MS Windows explorer shell integration; filemanagers integration
(Nautilus, Konqueror)
- side by side diffs in gitweb, a la KDiff3/Meld/ediff etc.
* code:
- port scripts to C (builtinification)
- git library (libification)
- gitbox: single static, pre-packaged binary
* other:
- bisect dunno / skip / next
- partial checkout
- light working copies; multiple working copies per repo
- git-notes, to annotate commit messages
- push over sftp
- option to track empty directories
- option to track permissions and metainfo: ACL, EA, forks
- rebase and blame merge strategies
- merge / rebase into dirty tree
- resumable git-clone; faster and less CPU hungry git-clone
- checkout/merge/diff/hunk header handlers in distribution for
ChangeLog, XML, odf, jar and xul, po files
This is only [large] excerpt, not a list of all requested features.
As one can see tabularizing (dividing into categories) this data will
be not an easy task.
38. If you want to see GIT more widely used, what do you think
we could do to make this happen?
TO DO
459 / 683 non-empty responses
So many suggestions...
One of the more striking (and funny):
* Big fat posters world-wide with Catherine Zeta-Jones stating how
happy she is since she switched to git ;-)
She can actually write C-code.
* Offer Git stickers to put on laptops and such
Changes in GIT (since year ago, or since you started using it)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
39. Did you participate in previous Git User's Survey?
Answer | Count
------------------------------------------
Yes | 51
No | 583
------------------------------------------
Base | 634 / 683
Total (sum) | 634
51 people did out of 634 who answered this question, out of 115 (?)
who did participate in the previous survey. Around half. Bit curious.
40. What improvements you wanted got implemented?
TO TABULARIZE
129 / 683 non-empty responses
41. What improvements you wanted didn't get implemented?
TO TABULARIZE
104 / 683 non-empty responses
42. How do you compare current version with version from year ago?
Should be: from year ago, or since you started using this.
No responses (303 / 683) migh be caused by the fact that one
do not use git for a year, so he/she doesn't know what git
looked like year ago.
Answer | Count
------------------------------------------
Better | 319
No changes | 60
Worse | 1
------------------------------------------
Base | 380 / 683
Total (sum) | 380
Most think that git has improved. One user thinks that it is worse
than year ago; I wonder why...
43. Which of the new features do you use?
Multiple choice; the list does not include all new features.
Some new features are not visible at first glance, and one
uses them without conscious choice.
Answer | Count
------------------------------------------
git-gui | 103
blame improvements | 74
detached HEAD | 71
stash | 68
mergetool | 67
interactive rebase | 66
reflog | 54
submodules | 52
shallow clone | 31
commit template | 24
eol conversion | 22
gitattributes | 21
bundle | 17
worktree | 17
------------------------------------------
Base | 259 / 683
Total (sum) | 687
This table is sorted by count.
Detached HEAD support and stash command were long requested;
no wonder they are popular.
Documentation
~~~~~~~~~~~~~
Usefulness of | Yes / Some / No | Base
----------------------------------------------
GIT wiki | 191 / 69 / 198 | 458
on-line help | 377 / 172 / 28 | 577
distributed help | 425 / 154 / 22 | 601
----------------------------------------------
individual responses : 683
44. Do you use the GIT wiki?
Answer | Count
------------------------------------------
Yes | 316
No | 300
------------------------------------------
Base | 616 / 683
Total (sum) | 616
45. Do you find GIT wiki useful?
Answer | Count
------------------------------------------
Yes | 191
No | 69
Somewhat | 198
------------------------------------------
Base | 458 / 683
Total (sum) | 458
46. Do you contribute to GIT wiki?
Answer | Count
------------------------------------------
Yes | 17
No | 460
Corrections and removing spam | 45
Some contribution | 62
------------------------------------------
Base | 522 / 683
Total (sum) | 522
47. Do you find GIT's on-line help (homepage, documentation) useful?
Answer | Count
------------------------------------------
Yes | 377
No | 28
Somewhat | 172
------------------------------------------
Base | 577 / 683
Total (sum) | 577
48. Do you find help distributed with GIT useful
(manpages, manual, tutorial, HOWTO, release notes)?
Answer | Count
------------------------------------------
Yes | 425
No | 22
Somewhat | 154
------------------------------------------
Base | 601 / 683
Total (sum) | 601
49. Did/Do you contribute to GIT documentation?
Answer | Count
------------------------------------------
Yes | 43
No | 551
------------------------------------------
Base | 594 / 683
Total (sum) | 594
50. What could be improved on the GIT homepage?
TO DO
171 / 683 non-empty responses
51. What topics would you like to have on GIT wiki?
TO DO
134 / 683 non-empty responses
52. What could be improved in GIT documentation?
TO DO
190 / 683 non-empty responses
Getting help, staying in touch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Do you use | Yes / No | Base
----------------------------------------------
GIT wiki | 316 / 300 | 616
mailing list | 204 / 406 | 610
IRC channel | 182 / 376 | 558
----------------------------------------------
Usefulness of | Yes / Some / No | Base
----------------------------------------------
GIT wiki | 191 / 69 / 198 | 458
mailing list | 146 / 79 / 34 | 259
IRC channel | 127 / 59 / 26 | 212
----------------------------------------------
individual responses : 683
As one can see mailing list is the primary medium for git,
and IRC secondary one.
53. Have you tried to get GIT help from other people?
Answer | Count
------------------------------------------
Yes | 357
No | 261
------------------------------------------
Base | 618 / 683
Total (sum) | 618
It might be that Git is not documented enough; it might be that
version control is not an easy task.
54. If yes, did you get these problems resolved quickly
and to your liking?
Answer | Count
------------------------------------------
Yes | 326
No | 53
------------------------------------------
Base | 379 / 683
Total (sum) | 379
That is I think very good (around 86%) percentage.
55. Would commerical (paid) support from a support vendor
be of interest to you/your organization?
Answer | Count
------------------------------------------
Not Applicable | 203
Yes | 69
No | 322
Yes + No | 391
------------------------------------------
Base | 594 / 683
Total (sum) | 594
Only 69 (12%) answers yes, 322 no, 203 not applicable (which meant
to encompass people who do not use git at and for work).
433 = 56 + 377 people participating in this survey use git for work,
or for both work and unpaid projects (as compared to 391 who answered
this question not with N/A).
Note that Git is GPLv2, and it will probably stay that forever, so you
are _free_ to start a commercial support scheme for Git, but others
are free not to choose it. This question is to get to know if there is
sufficient demand for commercial Git support for it to be viable.
56. Do you read the mailing list?
Answer | Count
------------------------------------------
Yes | 204
No | 406
------------------------------------------
Base | 610 / 683
Total (sum) | 610
The fact that only one third of git users are reading mailing list
(which is nevertheless quite large percentage) means that features
_have_ to be documented somewhere besides mailing list archive and
logs (commit messages).
57. If yes, do you find the mailing list useful?
Answer | Count
------------------------------------------
Yes | 146
No | 34
Somewhat | 79
------------------------------------------
Base | 259 / 683
Total (sum) | 259
58. Do you find traffic levels on GIT mailing list OK?
Answer | Count
------------------------------------------
Yes | 193
No | 50
------------------------------------------
Base | 243 / 683
Total (sum) | 243
59. Do you use the IRC channel (#git on irc.freenode.net)?
Answer | Count
------------------------------------------
Yes | 182
No | 376
------------------------------------------
Base | 558 / 683
Total (sum) | 558
60. If yes, do you find IRC channel useful?
Answer | Count
------------------------------------------
Yes | 127
No | 26
Somewhat | 59
------------------------------------------
Base | 212 / 683
Total (sum) | 212
61. Did you have problems getting GIT help on mailing list
or on IRC channel? What were it? What could be improved?
TO TABULARIZE
99 / 683 non-empty responses
Open forum
~~~~~~~~~~
62. What other comments or suggestions do you have, that are not
covered by the questions above?
TO DO
141 / 683 non-empty responses
--
Jakub Narebski
^ permalink raw reply
* Re: [PATCH 5/5] Use start_comand() in builtin-fetch-pack.c instead of explicit fork/exec.
From: Junio C Hamano @ 2007-10-04 8:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <1191442180-15905-6-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt <johannes.sixt@telecom.at> writes:
> Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
> ---
> fetch-pack.c | 35 ++++++++++-------------------------
> 1 files changed, 10 insertions(+), 25 deletions(-)
>
> diff --git a/fetch-pack.c b/fetch-pack.c
> index d06b5ec..80268e1 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -502,9 +503,12 @@ static int get_pack(int xd[2])
> char hdr_arg[256];
> const char **av;
> int do_keep = keep_pack;
> + struct child_process cmd;
>
> side_pid = setup_sideband(fd, xd);
>
> + memset(&cmd, 0, sizeof(cmd));
> + cmd.argv = argv;
> av = argv;
> *hdr_arg = 0;
> if (unpack_limit) {
Your patch to this function makes status and pid unused
variables, which I've fixed up locally.
The tip of your topic is currently queued to the tip of 'pu';
there were quite severe merge conflicts (textual conflicts in
builtin-fetch-pack.c, and adjustment to transport.c for
semantics change was also needed), so I ended up doing an evil
merge there, which I am not very happy about.
I suspect the evil-merge's changes to builtin-fetch-pack to
handle the connection to the index-pack process may be quite
busted, but I ran out of time. Please check if the result makes
sense, Ok?
I think Daniel and Shawn's git-fetch-in-C should graduate
'master' before this series. If you can re-send the series
rebased on 2b5a06edca8f7237aad6464b349b79772024d2a2 (Restore
default verbosity for http fetches.), it would be much
appreciated.
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Martin Waitz @ 2007-10-04 8:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <7vir5nb89d.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 608 bytes --]
hoi :)
On Thu, Oct 04, 2007 at 01:21:02AM -0700, Junio C Hamano wrote:
> FWIW, I did not mean it to be an example for preferred
> indentation nor code layout, but as a better way to explain what
> the logic is computing.
sure, and I think it makes sense the way you wrote it.
> I do not think git on Cygwin nor WinGit creates $GIT_DIR/config
> with executable bit set. Is this pretty much a workaround only
> for vfat-on-Linux ?
I just checked Cygwin, it creates files without executable bit and
disregards a chmod +x. So yes, this seems to be a Linux-only problem.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: making "git stash" safer to use
From: Joachim B Haga @ 2007-10-04 8:40 UTC (permalink / raw)
To: git
In-Reply-To: <200710032331.41385.bruno@clisp.org>
> Through a simple typo I lost modifications to 20 files:
>
>> >>> $ git stash
>> >>> $ git pull
>> >>> $ git stash apply
>> >>> $ git stash clean # typo!
>> >>> $ git stash clear # fatal correction to typo!
>
> It is just too easy to lose your modifications by using "git stash".
What makes it most dangerous is that there is no differentiation
between a name and a command in the same position. I'd argue that
either the command should be mandatory:
git stash save mywork
git stash apply mywork
git stash clear mywork
git stash mywork # error
(we can still keep today's shortcuts "git stash" and "git stash apply",
but only for the un-named case),
or that the command should be of the option type:
git stash mywork
git stash --apply mywork
git stash --clear mywork
-j.
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Johannes Sixt @ 2007-10-04 8:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <7vir5nb89d.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Martin Waitz <tali@admingilde.org> writes:
>> On Wed, Oct 03, 2007 at 11:23:22PM -0700, Junio C Hamano wrote:
>>> filemode = !( (st1.st_mode & S_IXUSR)
>>> /* we did not ask for x-bit -- bogus FS */
>>> || chmod(path, st1.st_mode & S_IXUSR)
>>> /* it does not let us flip x-bit -- bogus FS */
>>> || lstat(path, &st2)
>>> /* it does not let us read back -- bogus FS */
>>> || (st1.st_mode == st2.st_mode)
>>> /* it forgets we flipped -- bogus FS */
>>> );
>> that looks good.
>
> I do not think git on Cygwin nor WinGit creates $GIT_DIR/config
> with executable bit set. Is this pretty much a workaround only
> for vfat-on-Linux ?
I think so. Here on Windows, 'ls -l' after 'git init' tells that .git/config
is not executable (both FAT and NTFS). But, anyway, as far as the MinGW port
is concerned, at least the last condition in the sequence above triggers and
causes filemode=false, which is good.
-- Hannes
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Karl Hasselström @ 2007-10-04 8:33 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910710032229m38fb4e47k5aa0b2b2e0eb2251@mail.gmail.com>
On 2007-10-04 01:29:17 -0400, Jon Smirl wrote:
> for some reason the refresh from that command didn't close. Then stg
> pushed all the patches back after the edit and they got included
> into that patch.
That's really weird. As far as I know there isn't a concept of
"closed" patches in StGit -- there's no need, because they're always
closed!
> I did the 'stg refresh' from a directory that was not being tracked
> by git. It is in the .gitignore list. This appears to be the root of
> the problem.
Mmmph. This is not the only StGit command that's apparently not safe
to run from a subdirectory. See e.g. https://gna.org/bugs/?9986.
I plan to do some StGit hacking this weekend. I guess subdirectory
safeness ought to be at the top of my list ...
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stgit: editing description of patch
From: Karl Hasselström @ 2007-10-04 8:26 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910710031914r766efa88pad9f55f9495d127e@mail.gmail.com>
On 2007-10-03 22:14:20 -0400, Jon Smirl wrote:
> On 10/3/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>
> > What is the right procedure for editing the various attributes of
> > a stgit patch? patch name, description, etc.... I just emailed a
> > series to myself and the titles/comments are all messed up.
>
> Editing these is done with the stg refresh command.
This is "stg edit" in really new StGits.
> > On my box all of the patches have names -- stg series shows them.
> > But when I emailed them half of the patch didn't have the right
> > subjects.
>
> this is controled in the template files
Anything here you'd characterize as a bug?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Junio C Hamano @ 2007-10-04 8:21 UTC (permalink / raw)
To: Martin Waitz; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <20071004071751.GD20800@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> hoi :)
>
> On Wed, Oct 03, 2007 at 11:23:22PM -0700, Junio C Hamano wrote:
>> filemode = !( (st1.st_mode & S_IXUSR)
>> /* we did not ask for x-bit -- bogus FS */
>> || chmod(path, st1.st_mode & S_IXUSR)
>> /* it does not let us flip x-bit -- bogus FS */
>> || lstat(path, &st2)
>> /* it does not let us read back -- bogus FS */
>> || (st1.st_mode == st2.st_mode)
>> /* it forgets we flipped -- bogus FS */
>> );
>
> that looks good.
FWIW, I did not mean it to be an example for preferred
indentation nor code layout, but as a better way to explain what
the logic is computing.
I do not think git on Cygwin nor WinGit creates $GIT_DIR/config
with executable bit set. Is this pretty much a workaround only
for vfat-on-Linux ?
^ permalink raw reply
* Re: git-cvsserver commit trouble (unexpected end of file in client)
From: Jan Wielemaker @ 2007-10-04 7:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710032311480.28395@racer.site>
Hi Dscho,
Thanks for the comments. I'll keep in on the list, just in case there is
someone else with a brilliant idea.
On Thursday 04 October 2007 00:14, you wrote:
> Hi,
>
> On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> > On Wednesday 03 October 2007 20:55, you wrote:
> > > On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> > > > On Wednesday 03 October 2007 18:11, Johannes Schindelin wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, 3 Oct 2007, Jan Wielemaker wrote:
> > > > > > 2007-10-03 12:25:16 : WARN - error 1 pserver cannot find the
> > > > > > current HEAD of module
> > > > >
> > > > > AFAIR we do not allow committing via pserver protocol. Might that
> > > > > be your problem?
> > > >
> > > > Thanks, but no. I'm using CVS over SSH. I've been looking around in
> > > > git-cvsserver source a bit and it aborts quite quickly if you try a
> > > > commit through pserver. I get a bit further, but it cannot find the
> > > > HEAD revision for some reason and (from later message), if I try to
> > > > checkout master instead of HEAD it finds the revision but I get a
> > > > hash mismatch.
> > >
> > > Okay, another stab: is your HEAD detached?
> >
> > I'm a humble git beginner, though I think *my* head is still attached
> > :-) In any case, we are talking a fresh repository and I can perfectly
> > well clone it as well as pull and push from the clone using GIT
> > commands. How do I tell whether the HEAD is detached?
>
> You can tell by looking into .git/HEAD (on the side that runs the server).
> If it is a 40-character hex string, the HEAD is detached. Otherwise, it
> should contain something like "refs/heads/master".
Its the latter, so my HEAD is still attached. I hope I understand this
correctly, but browsing the docs suggests a detached head is not really
a normal situation, so I'm fine. Right?
> Other reasons for the failure could be:
>
> - your user does not have write access
Definitely ok (also put an strace -o logfile git-cvsserver "$@" script
around it. No alarming permission or non-existence errors).
> - the uid under which git-cvsserver runs has no write access
See above
> - you found an error that only triggers with your repo
Great! Its so damn simple and and tried with three repos created
in three different ways, that I'm either extremely unlucky or many
more should be faced with this or nobody uses git-cvsserver.
I'm hoping for a command-by-command sequence that gets me a definitely
fine repository, so at least I can see it running correctly once. Then
maybe I can analyse traces in detail to see where they differ and what
is wrong. Somebody?
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Martin Waitz @ 2007-10-04 7:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <7vr6kbbdph.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 509 bytes --]
hoi :)
On Wed, Oct 03, 2007 at 11:23:22PM -0700, Junio C Hamano wrote:
> filemode = !( (st1.st_mode & S_IXUSR)
> /* we did not ask for x-bit -- bogus FS */
> || chmod(path, st1.st_mode & S_IXUSR)
> /* it does not let us flip x-bit -- bogus FS */
> || lstat(path, &st2)
> /* it does not let us read back -- bogus FS */
> || (st1.st_mode == st2.st_mode)
> /* it forgets we flipped -- bogus FS */
> );
that looks good.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: size_t vs "unsigned long"
From: Jan Wielemaker @ 2007-10-04 7:16 UTC (permalink / raw)
To: git
In-Reply-To: <20071003213601.GD28188@artemis.corp>
On Wednesday 03 October 2007 23:36, Pierre Habouzit wrote:
> On Wed, Oct 03, 2007 at 09:19:59PM +0000, Jan Wielemaker wrote:
> > On Wednesday 03 October 2007 22:48, Pierre Habouzit wrote:
> > > On Wed, Oct 03, 2007 at 08:30:04PM +0000, Junio C Hamano wrote:
> > > > Traditionally, inside git, we have used the length of things
> > > > with "unsigned long" for pretty much anything, except where we
> > > > wanted the length exactly sized we used int32_t, uint64_t and
> > > > friends.
> > > >
> > > > A few places pass pointer to unsigned long as the second
> > > > parameter to strbuf_detach(), triggering type mismatch warnings.
> > > > An easy way out is to change strbuf_detach() to take a pointer
> > > > to ulong but I think it is going backwards. Most places that
> > > > use "unsigned long" can safely be converted (and made more
> > > > correct) to use size_t.
> > >
> > > Well, afaict, on every linux archs I know of, unsigned longs and
> > > size_t are the same. Though, I don't know if that holds for the msys
> > > port, and if that does not holds, then a s/unsigned long/size_t/ would
> > > help them. Else, for consistency sake, I believe the change is a good
> > > one.
> >
> > Surely on the Microsoft 64-bit compilers size_t is 64-bits and long is
> > 32-bits. Don't blame me, I'm just the messenger that learned the hard
> > way ...
>
> Yeah, I've been wondering, and it's the information I had. well, the
> information I had is that sizeof(size_t) is 4 on win32, and 8 on win64,
> OTOH (and this one I'm sure), on windows, longs are 32bits on both (32
> and 64 bits ABIs).
>
> So replacing unsigned long with size_t's will help the msys port,
> hence I had some insight that this could prove useful, now I'm sure :)
The other types that are useful are intptr_t and uintptr_t, integers
that are guaranteed to be able to hold a pointer. They are defined by
recent versions of the Microsoft compilers and are in <inttypes.h> in
most POSIX systems (at least I didn't have complaints since I started
using them). I use them for integers holding mangled pointers. Of
course most clean C programs should not need that.
--- Jan
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Martin Waitz @ 2007-10-04 7:15 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710040053380.28395@racer.site>
[-- Attachment #1: Type: text/plain, Size: 504 bytes --]
hoi :)
On Thu, Oct 04, 2007 at 12:54:06AM +0100, Johannes Schindelin wrote:
> > - filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
> > + /* test that new files are not created with X bit */
> > + filemode = !(st1.st_mode & S_IXUSR);
> > + /* test that we can modify the X bit */
> > + filemode &= (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>
> Should that not be &&=?
originally I wrote it that way but the compiler complaint.
I guess we are too used to perl ;-)
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-10-04 7:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Kastrup, Jeff King, Git Mailing List
In-Reply-To: <alpine.LFD.0.999.0710021916080.3579@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Hmm. The patch depends on half-way subtle issues like the fact that the
> hashtables are guaranteed to not be full => we're guaranteed to have zero
> counts at the end => we don't need to do any steenking iterator count in
> the loop. A few comments might in order.
The patch actually is quite readable. That double-loop finding
the matching hashval in destination hash was simply silly to
begin with, so even if this is not "orders of magnitude"
improvement, I think your patch is worth doing.
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Martin Langhoff @ 2007-10-04 6:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Wincent Colaiuta, David Kastrup, Johannes Schindelin, git,
msysgit
In-Reply-To: <7vd4vwfou9.fsf@gitster.siamese.dyndns.org>
Junio,
great summary!
On 10/3/07, Junio C Hamano <gitster@pobox.com> wrote:
> One thing Linus had to say about the issue from early on, and I
> still agree with, is the last paragraph in:
>
> http://article.gmane.org/gmane.comp.version-control.git/2298
I'm in complete agreement here...
...
> I've seen markdown used elsewhere, and I regularly read pod.
...
> How good are HTML and manpage output support from these (or
> other candidates) formats these days? Output to help page
> format Windows folks use (I am assuming Mac people are happy as
> long as man is available) would be a definite plus.
And something that leads to PDF (perhaps via latex).
The problem I see here -- and that I've bumped into several times in
other projects -- is that readable & easy to edit text formats for the
source are key, and those can do most of what we need for
man/info/html outputs. But documentation formats that produce high
quality print output usually need arcane formats _and_ a
high-maintenance toolchain.
With AsciiDoc we've managed to avoid the arcane format, but we are
still laden with a horrid toolchain. In that light, I actually like
what Johannes is doing, even though it's a timesink.
Do the other text based alternatives these days have a workable high
quality PDF/latex output format without pulling in brittle
dependencies like XSLT?
cheers
martin
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Junio C Hamano @ 2007-10-04 6:23 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, Martin Waitz, git
In-Reply-To: <470482A2.3080907@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Johannes Schindelin wrote:
>> Hi,
>>
>> On Thu, 4 Oct 2007, Martin Waitz wrote:
>>
>>> - filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>>> + /* test that new files are not created with X bit */
>>> + filemode = !(st1.st_mode & S_IXUSR);
>>> + /* test that we can modify the X bit */
>>> + filemode &= (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>>
>> Should that not be &&=?
>>
>
> I should think |=
Is it?
The issue that started the thread was that chmod + stat check we
originally had would say executable bit "seems to be" kept,
while that is only true until the information is cached at VFS
layer.
We create config file without asking for executable bit, so if
we read it back as executable then that is a sure sign that the
filesystem does not know what it is talking about, and we set
filemode to zero in such a case. Similarly, if the chmod + stat
check says we cannot set executable bit and read it back, then
we also know the filesystem does not know about filemode.
So I think we can write it like this (indentation aside)...
filemode = !( (st1.st_mode & S_IXUSR)
/* we did not ask for x-bit -- bogus FS */
|| chmod(path, st1.st_mode & S_IXUSR)
/* it does not let us flip x-bit -- bogus FS */
|| lstat(path, &st2)
/* it does not let us read back -- bogus FS */
|| (st1.st_mode == st2.st_mode)
/* it forgets we flipped -- bogus FS */
);
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Andreas Ericsson @ 2007-10-04 6:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Martin Waitz, git
In-Reply-To: <Pine.LNX.4.64.0710040053380.28395@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Thu, 4 Oct 2007, Martin Waitz wrote:
>
>> - filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>> + /* test that new files are not created with X bit */
>> + filemode = !(st1.st_mode & S_IXUSR);
>> + /* test that we can modify the X bit */
>> + filemode &= (!chmod(path, st1.st_mode ^ S_IXUSR) &&
>
> Should that not be &&=?
>
I should think |=
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* stgit: lost all my patches again
From: Jon Smirl @ 2007-10-04 5:29 UTC (permalink / raw)
To: Git Mailing List
I believe this command did it:
stg refresh -p pcm030_bsp_powerpc -e
that patch whitespace errors in it
I edited the description and removed the last line
it was 10th patch down in the stack
for some reason the refresh from that command didn't close.
Then stg pushed all the patches back after the edit and they got
included into that patch.
stg should definitely have an assert that the previous patch is closed
before auto pushing.
There is a bug somewhere that caused that edit refresh not to get closed.
I am using stg version:
5ae6fcce77a29221e15f6a4e8348bd4276960ba1
It might also be good to make a log that lets me rollback commands.
All of the info is still in the system.
This refresh failed to close:
jonsmirl@terra:~/mpc5200b$ stg log pcm030_bsp_powerpc
95a8e03b [push ] Thu Oct 4 00:27:53 2007 -0400
6094a0a5 [refresh] Thu Oct 4 00:00:41 2007 -0400
0c4f5480 [push(f)] Wed Oct 3 22:10:38 2007 -0400
9a685ae9 [push(f)] Wed Oct 3 22:05:47 2007 -0400
This push ended up in the bsp patch:
jonsmirl@terra:~/mpc5200b$ stg log mpc52xx_restart
801962ed [push ] Thu Oct 4 00:33:42 2007 -0400
9e0c7417 [push ] Thu Oct 4 00:27:53 2007 -0400
37822491 [push ] Thu Oct 4 00:00:41 2007 -0400
9aff07ff [push(f)] Wed Oct 3 22:10:38 2007 -0400
c41c9cb3 [push(f)] Wed Oct 3 22:05:47 2007 -0400
and so one for nine more patches.
The ten messed up patches still have their descriptions, the are just
missing the changes.
---------------------------------
After an export stg puts the patches into patches-m25
Looking back in my command logs I had done:
stg export
cd patches-m25
grep for some things
stg refresh -p pcm030_bsp_powerpc -e
I did the 'stg refresh' from a directory that was not being tracked by git.
It is in the .gitignore list. This appears to be the root of the problem.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Sam Vilain @ 2007-10-04 4:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710030506360.28395@racer.site>
Johannes,
Given other people have answered some points, I'll answer the rest.
Johannes Schindelin wrote:
>>> -- snip --
>>> #!/usr/bin/perl
>> Add -w for warnings, also use strict;
>
> <dumb>What does "use strict;" imply?</dumb>
Three things;
1. variables must be declared with 'my', 'our' or 'use var' before they
are used, to catch typos
2. when subroutine calls are found, they are checked to exist otherwise
they throw a compile-time error
3. force all dereferences to follow real references and not allow symbol
table access (don't worry about that ;-))
>>> sub handle_text {
>> this function acts on globals; make them explicit arguments to the
>> function.
>
> Actually, it resets the global $par. Should I rather make it a class?
Well, just channelling Dijkstra really. Functions should take all their
input as formal arguments rather than globals.
ie
sub handle_text {
my $par = shift;
}
If it really should be a global, it is perhaps best declared up front
with "our" or "use vars". "use strict" will force you to do one of these.
>> also consider making this a "tabular ternary" with the actions in
>> separate functions.
>>
>> ie
>>
>> $result = ( $par =~ /^\. /s ? $conv->do_enum($par) :
>> $par =~ /^\[verse\]/ ? $conv->do_verse($par) :
>> ... )
>
> I do not like that way... is it Perl standard to code like that?
It's in Perl Best Practices, but these are always suggestions and not
hard and fast rules. It just means that you have a big table of regex
-> function that you can quickly check rather than looking at a lot of
spaced out 'elsif's
>>> s/gitlink:([^\[ ]*)\[(\d+)\]/sprintf "%s",
>>> $conv->get_link($1, $2)/ge;
>>> # handle link:
>>> s/link:([^\[ ]*)\[(.+)\]/sprintf "%s",
>>> $conv->get_link($1, $2, 'external')/ge;
>> These REs suffer from LTS (Leaning Toothpick Syndrome). Consider using
>> s{foo}{bar} and adding the 'x' modifier to space out groups.
>
> I guess you mean the forward slash. Alas, that's what I'm used to, and
> I'd rather not change it unless forced to... lest I stop understanding my
> own code!
>
> (Besides, I did not find _any_ example showing why "x" should be useful.)
Before:
s/link:([^\[ ]*)\[(.+)\]/sprintf "%s",
$conv->get_link($1, $2, 'external')/ge;
After:
s{ link: ([^\[\040]*) \[(.+)\] }
{ sprintf "%s", $conv->get_link($1, $2, 'external') }gex;
>>> if ($self->{preamble_shown} == undef) {
>>> print '.\" disable hyphenation' . "\n"
>>> . '.nh' . "\n"
>>> . '.\" disable justification (adjust text to left'
>>> . ' margin only)' . "\n"
>>> . '.ad l' . "\n";
>> Using commas rather than "." will safe you a concat when printing to
>> filehandles, but that's a very small nit to pick :)
>
> Does that also work with older perl? IIRC there was some strange problem
> with my perl when lots of code in git.git was changed to using commata.
That should go back all the way to perl 4, if not earlier. If you're
assigning to a scalar, then you need to use concat. But very minor.
>> Hmm, that regex would not match for <<foo > bar>>, if you care you'd
>> need to write something like <<((?:[^>]+|>[^>])*)>>
>
> I'd rather leave it as is -- this script is not meant to grok all kind of
> sh*t. It is meant to make translating the docs as fast and uncumbersome
> as possible. Which will involve making the documentation more consistent
> (in and of itself something I rather like).
>
> So unless there comes a compelling reason, I'd rather leave it.
Sure, KISS.
> Another thing: if I want to add some documentation, what would be the
> common way to do it? =pod...=cut?
That's right. If you're an emacs user, in cperl-mode with abbrevs on
you type '=head1' and you'll get:
=head1 NAME
scriptname
=head1 SYNOPSIS
=head1 DESCRIPTION
=cut
See perlpod(3) for more!
Sam.
^ permalink raw reply
* Re: stgit: editing description of patch
From: Jon Smirl @ 2007-10-04 2:14 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <9e4733910710031626kff59666y77ba9001c0fef907@mail.gmail.com>
On 10/3/07, Jon Smirl <jonsmirl@gmail.com> wrote:
> What is the right procedure for editing the various attributes of a
> stgit patch? patch name, description, etc.... I just emailed a series
> to myself and the titles/comments are all messed up.
Editing these is done with the stg refresh command.
>
> On my box all of the patches have names -- stg series shows them. But
> when I emailed them half of the patch didn't have the right subjects.
this is controled in the template files
>
> --
> Jon Smirl
> jonsmirl@gmail.com
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* [PATCH] Use exit 1 instead of die when req_Root fails.
From: Brian Gernhardt @ 2007-10-04 1:43 UTC (permalink / raw)
To: git
In-Reply-To: <20071004011954.GK18024@planck.djpig.de>
This was causing test failures because die was exiting 255.
---
This finally takes care of my test failures.
git-cvsserver.perl | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 13dbd27..0d55fec 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -145,8 +145,10 @@ if ($state->{method} eq 'pserver') {
}
my $request = $1;
$line = <STDIN>; chomp $line;
- req_Root('root', $line) # reuse Root
- or die "E Invalid root $line \n";
+ unless (req_Root('root', $line)) { # reuse Root
+ print "E Invalid root $line \n";
+ exit 1;
+ }
$line = <STDIN>; chomp $line;
unless ($line eq 'anonymous') {
print "E Only anonymous user allowed via pserver\n";
--
1.5.3.4.203.gcc61a
^ permalink raw reply related
* Re: git-cvsserver test failures (still)
From: Frank Lichtenheld @ 2007-10-04 1:19 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git Mailing List
In-Reply-To: <A78B5F62-4FCC-4650-9B0D-0F64FEDB8423@silverinsanity.com>
Hi.
Some investigations on this:
On Wed, Oct 03, 2007 at 03:50:18PM -0400, Brian Gernhardt wrote:
> This appears to be from git-cvsserver.perl:148-9:
>
> req_Root('root', $line) # reuse Root
> or die "E Invalid root $line \n";
>
> This fails the test suite because die() exits with code 255 (checked
> with "perl -e 'die'; echo $?"), which is outside what
> test_expect_failure accepts (see t/test-lib.sh:179).
>
> My questions become:
> 1) Why hasn't this hit anyone else?
die doesn't always quit with 255:
"exits with the current value of $! (errno). If $! is 0, exits with the
value of "($? >> 8)" (backtick ‘command‘ status). If "($? >> 8)" is 0,
exits with 255"
On my system $! is 9 for these cases and so it exits with exit code 9.
> 2) Is this where these tests are supposed to fail?
yes, IIRC
> 3) If it is, should the code be using print and exit 1 instead of die?
I think that would be the best solution, yes.
> 4) If not, should the test be altered to end with "|| false" or
> similar so the test passes?
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] Be nice with compilers that do not support runtime paths at all.
From: Brian Gernhardt @ 2007-10-04 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Benoit Sigoure, git
In-Reply-To: <7vejgbdbyn.fsf@gitster.siamese.dyndns.org>
On Oct 3, 2007, at 7:18 PM, Junio C Hamano wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> writes:
>
>> @@ -507,6 +510,7 @@ ifeq ($(uname_S),Darwin)
>> BASIC_LDFLAGS += -L/opt/local/lib
>> endif
>> endif
>> + NO_RPATH = YesPlease
>> endif
>
> I'll let Darwin users to fight the defaults for this part out.
It makes sense, since Apple's gcc/ld/dyld doesn't use rpath.
~~ Brian
^ permalink raw reply
* Re: [PATCH] Be nice with compilers that do not support runtime paths at all.
From: Brian Gernhardt @ 2007-10-04 1:08 UTC (permalink / raw)
To: Steven Grimm; +Cc: Benoit Sigoure, git
In-Reply-To: <47041C7A.9090003@midwinter.com>
On Oct 3, 2007, at 6:49 PM, Steven Grimm wrote:
> Benoit Sigoure wrote:
>> On Darwin for instance, there is no -R or -Wl,-rpath thing to
>> fiddle with,
>> it's simply not supported by the dynamic loader. This patch
>> introduces a
>> NO_RPATH define which is enabled by default for Darwin.
>>
>
> I compile git on a MacBook Pro (OS X 10.4, gcc 4.0.1 build 5367
> from the normal Xcode install that comes on the OS install DVD) on
> a regular basis. The makefile works fine for me. I suspect there's
> something else going on here.
The rpath code is only used if you define one of the following options:
CURLDIR
ZLIB_PATH
OPENSSLDIR
ICONVDIR
The default Darwin options don't define any of these, it just relies
on finding those libraries in the library path (including /sw or /opt/
local if you have them installed).
~~ Brian G.
^ permalink raw reply
* [PATCH] builtin-apply: fix conversion error in strbuf series
From: Junio C Hamano @ 2007-10-04 0:53 UTC (permalink / raw)
To: git
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-apply.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-apply.c b/builtin-apply.c
index 047a60d..05c6bc3 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2651,7 +2651,7 @@ static int apply_patch(int fd, const char *filename, int inaccurate_eof)
patch = xcalloc(1, sizeof(*patch));
patch->inaccurate_eof = inaccurate_eof;
- nr = parse_chunk(buf.buf + offset, buf.len, patch);
+ nr = parse_chunk(buf.buf + offset, buf.len - offset, patch);
if (nr < 0)
break;
if (apply_in_reverse)
--
1.5.3.4.1150.gbb28
^ permalink raw reply related
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Johannes Schindelin @ 2007-10-03 23:54 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20071003231941.GA20800@admingilde.org>
Hi,
On Thu, 4 Oct 2007, Martin Waitz wrote:
> - filemode = (!chmod(path, st1.st_mode ^ S_IXUSR) &&
> + /* test that new files are not created with X bit */
> + filemode = !(st1.st_mode & S_IXUSR);
> + /* test that we can modify the X bit */
> + filemode &= (!chmod(path, st1.st_mode ^ S_IXUSR) &&
Should that not be &&=?
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox