* Re: [PATCH] Add a simple option parser.
From: Kristian Høgsberg @ 2007-10-04 14:57 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git, gitster
In-Reply-To: <20071003231145.GF28188@artemis.corp>
On Thu, 2007-10-04 at 01:11 +0200, Pierre Habouzit wrote:
> On Wed, Oct 03, 2007 at 09:45:01PM +0000, Kristian Høgsberg wrote:
> > The option parser takes argc, argv, an array of struct option
> > and a usage string. Each of the struct option elements in the array
> > describes a valid option, its type and a pointer to the location where the
> > value is written. The entry point is parse_options(), which scans through
> > the given argv, and matches each option there against the list of valid
> > options. During the scan, argv is rewritten to only contain the
> > non-option command line arguments and the number of these is returned.
>
> if we are going in that direction (and I believe it's a good one), we
> should be sure that the model fits with other commands as well. And as I
> said on IRC, I believe the most "horrible" (as in complex) option parser
> in git is the one from git-grep.
>
> A migration of git-grep on that API should be tried first. If this
> works well enough, I believe that the rest of the git commands will be
> migrated easily enough. (with maybe small addition to parse-option.[hc]
> but the hardcore things should have been met with git-grep already I
> think).
I'm not sure - we can go with the current proposal and add new options
types and probably the callback option type I suggested as we go. I
don't want to block builtin-commit on figuring out what the perfect
option parser should look like and what I sent out earlier work for
commit. I think the way you handled the strbuf rewrites worked pretty
well; extending and rewriting the API as you put it to use in more and
more places. We can do the same thing with parse_options().
cheers,
Kristian
^ permalink raw reply
* Re: git push (mis ?)behavior
From: Steffen Prohaska @ 2007-10-04 14:47 UTC (permalink / raw)
To: Git Mailing List
Cc: Johannes Schindelin, Pierre Habouzit, Wincent Colaiuta,
Miles Bader, Junio C Hamano, Karl Hasselström
In-Reply-To: <20071003170241.GA7571@diana.vm.bytemark.co.uk>
On Oct 3, 2007, at 7:02 PM, Karl Hasselström wrote:
> On 2007-10-03 17:44:39 +0100, Johannes Schindelin wrote:
>
>> I wonder how hard it would be to teach _everybody_ to specify
>> _exactly_ what they want.
>>
>> Of course, we'd need an "--existing" option to git-push to trigger
>> the behaviour that we have right now.
>
> I could _definitely_ live with that. If the branch config doesn't say
> what to do when no arguments are given, then demand a specification on
> the command line.
>
> I'll shut up on this topic now, though, since I'm not exactly helping
> with the patch/opinion ratio.
Here is an interesting related pitfall where my expectations about
the behaviour of git push in relation with tracking branches were
wrong. I should have know better, but I somehow forgot the details.
I expected that the following would establish a two-way link, not
only a one way link:
git checkout --track -b mynext origin/next
sets up a tracking branch and "git pull" fetches and merges changes
from origin/next as expected.
I somehow expected that "git push" would push changes from mynext to
origin/next. But it doesn't. It would only do so if I had chosen
the same name for the local branch, that is
git checkout --track -b next origin/next
would have set up a two-way link -- but maybe only as long as I don't
have other push lines in my config file. I'm not sure about the last
point.
I do not find it very intuitive to mangle the push behaviour into the
naming of the local branch. I think it would be a good idea if the
two commands above would either both setup a pull/push relation
or both would setup a pull-only relation. If pull-only would be the
default another switch could be provided to establish a pull/push
relation, like
git checkout --track --push -b mynext origin/next
Comments?
Steffen
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Matthieu Moy @ 2007-10-04 14:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710041534000.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Thu, 4 Oct 2007, Junio C Hamano wrote:
>
>> * --cached means work only on index and ignore work tree.
>
> I guess I could live with "--staged" as a synonym for "--cached" (and
> maybe deprecating "--cached").
It makes more sense to me.
For me, a "cache" is a fast-access copy of something, that I can
rebuild at any time. Cache should be only a matter of performance, if
the "cache" for an application changes its functionality, it means the
cache has been too optimistic. Git's index is not that, "git add"
means "add this to the index", which itself means "put that in the
list of things to commit", and not "get a copy of that to work faster
with it".
So, to me (non-native speaker), "index" doesn't mean much, "cache" is
worse, it means something which isn't correct, and "staging area"
means the right thing (but is longer to type). For example, I
understand immediately when git-gui talks me about staging/unstaging
changes ;-).
--
Matthieu
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Junio C Hamano @ 2007-10-04 14:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0710041534000.4174@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Thu, 4 Oct 2007, Junio C Hamano wrote:
>
>> * --cached means work only on index and ignore work tree.
>
> I guess I could live with "--staged" as a synonym for "--cached" (and
> maybe deprecating "--cached").
A handy mnemonic might be:
* --index means work work tree through the index. Once you get
git, this is natural as you would not interact with files in
the work tree that is not known to the index.
* --cached means work only on the cached information in index.
Any change like swapping them or renaming --cached to --index
and making something else to mean what --index always meant will
break existing setups and people's scripts. Won't happen.
Giving them synonyms without deprecation is a viable option, if
necessary. I do not however see the need yet. A few people who
haven't learned the lingo of the land yet can worry about
possible confusion, but I do not think that "worry" itself does
not count as real need.
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Johannes Schindelin @ 2007-10-04 14:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 4 Oct 2007, Junio C Hamano wrote:
> * --cached means work only on index and ignore work tree.
I guess I could live with "--staged" as a synonym for "--cached" (and
maybe deprecating "--cached").
Ciao,
Dscho
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Wincent Colaiuta @ 2007-10-04 14:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org>
El 4/10/2007, a las 15:14, Junio C Hamano escribió:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi
>> <paolo.ciarrocchi@gmail.com> wrote:
>>> Why do we have the option "--cached" and not "--index"?
>>
>> according to glossary.txt, 'cache' is an obsolete for 'index'.
>> probably
>> this is the reason
>>
>> probably cache.h will be never renamed to index.h, i don't know if
>> diff
>> --cached will be ever renamed to diff --index
>
> Probably never.
>
> Some commands support both --index and --cached and have
> different meanings. For them,
>
> * --index means work on both index and work tree;
> * --cached means work only on index and ignore work tree.
Look at that with fresh eyes and you can see how it makes very little
sense.
The option named "--index" works on more than the index and the
option named "--cached" works only on the index. This sounds back-to-
front.
IMO, better names would be:
--index : means work only on the index (and ignore the work tree);
ie. it means what it says
--index-and-worktree : it also means what it says
The latter is more keystrokes but it's clearer.
Having said all this, I recognize that the likelihood of these option
names ever being changed is close to zero. Like Paolo says in his
other email, the documentation could be made clearer to avoid
possible confusion.
Cheers,
Wincent
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Paolo Ciarrocchi @ 2007-10-04 13:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <7vy7ej9g38.fsf@gitster.siamese.dyndns.org>
On 10/4/07, Junio C Hamano <gitster@pobox.com> wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> >> Why do we have the option "--cached" and not "--index"?
> >
> > according to glossary.txt, 'cache' is an obsolete for 'index'. probably
> > this is the reason
> >
> > probably cache.h will be never renamed to index.h, i don't know if diff
> > --cached will be ever renamed to diff --index
>
> Probably never.
Ouch!
> Some commands support both --index and --cached and have
> different meanings. For them,
>
> * --index means work on both index and work tree;
> * --cached means work only on index and ignore work tree.
>
> In the case of "diff --cached", the latter is exactly what's
> happening. We do not say "git diff-index --index $commit"
> because "git diff-index" (and by extension, when you give only
> one commit to "git diff" as parameter) is all about a commit vs
> your uncommitted changes, so having you say "--index" is just
> silly. "git diff --cached" is just a shorthand for "git diff
> --cached HEAD". Because --cached would make sense to no other
> form of diff, its presense by definition means you are talking
> about the one-tree form of diff i.e. compare a commit with your
> uncommitted changes.
I see. But the problem is real. If we cannot solve the problem
changing the code of git we'll need to avoid this kind of
misunderstanding having "better" documentation.
As soon as I'll find some spare time I'll propose a patch to "A
tutorial introduction to git (for version 1.5.1 or newer)".
Thanks!
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* [PATCH] fix t5403-post-checkout-hook.sh: built-in test in dash does not have "=="
From: Alex Riesen @ 2007-10-04 13:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Josh England, git
In-Reply-To: <1190842261-9750-1-git-send-email-jjengla@sandia.gov>
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Josh England, Wed, Sep 26, 2007 23:31:01 +0200:
> t/t5403-post-checkout-hook.sh | 74 +++++++++++++++++++++++++++++++++++++++++
on Ubuntu, /bin/sh is dash.
t/t5403-post-checkout-hook.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5403-post-checkout-hook.sh b/t/t5403-post-checkout-hook.sh
index 487abf3..823239a 100755
--- a/t/t5403-post-checkout-hook.sh
+++ b/t/t5403-post-checkout-hook.sh
@@ -39,7 +39,7 @@ test_expect_success 'post-checkout receives the right arguments with HEAD unchan
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag == 1
+ test $old = $new -a $flag = 1
'
test_expect_success 'post-checkout runs as expected ' '
@@ -52,7 +52,7 @@ test_expect_success 'post-checkout args are correct with git checkout -b ' '
old=$(awk "{print \$1}" clone1/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone1/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone1/.git/post-checkout.args) &&
- test $old = $new -a $flag == 1
+ test $old = $new -a $flag = 1
'
test_expect_success 'post-checkout receives the right args with HEAD changed ' '
@@ -60,7 +60,7 @@ test_expect_success 'post-checkout receives the right args with HEAD changed ' '
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old != $new -a $flag == 1
+ test $old != $new -a $flag = 1
'
test_expect_success 'post-checkout receives the right args when not switching branches ' '
@@ -68,7 +68,7 @@ test_expect_success 'post-checkout receives the right args when not switching br
old=$(awk "{print \$1}" clone2/.git/post-checkout.args) &&
new=$(awk "{print \$2}" clone2/.git/post-checkout.args) &&
flag=$(awk "{print \$3}" clone2/.git/post-checkout.args) &&
- test $old == $new -a $flag == 0
+ test $old = $new -a $flag = 0
'
test_done
--
1.5.3.3.147.g2054
^ permalink raw reply related
* Re: stgit: editing description of patch
From: Jon Smirl @ 2007-10-04 13:16 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071004082624.GA17778@diana.vm.bytemark.co.uk>
On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
> > > 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?
No, not after I have learned more about stg. The missing subjects were
from other patches I had imported from emails. They has all of the
email headers on them. Once I edited those out the subjects appeared
ok. 'stg edit' should help with this, it was non-obvious to use 'stg
refresh' to edit the patch descriptions.
Why is mailing a patch series so slow?
There also seems to be a disconnect when mailing patches. Locally the
patches have a name, when you email them it uses the short description
for the name by default instead of the local name. This may cause
confusion because the emailed name does not default to the local name.
A parallel issue happens on import.
Now that I am aware of the naming scheme I can deal with it, but this
may be a problem for new users. It might be better to force the short
description and local name to always match.
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Junio C Hamano @ 2007-10-04 13:14 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <20071004125641.GE15339@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
>> Why do we have the option "--cached" and not "--index"?
>
> according to glossary.txt, 'cache' is an obsolete for 'index'. probably
> this is the reason
>
> probably cache.h will be never renamed to index.h, i don't know if diff
> --cached will be ever renamed to diff --index
Probably never.
Some commands support both --index and --cached and have
different meanings. For them,
* --index means work on both index and work tree;
* --cached means work only on index and ignore work tree.
In the case of "diff --cached", the latter is exactly what's
happening. We do not say "git diff-index --index $commit"
because "git diff-index" (and by extension, when you give only
one commit to "git diff" as parameter) is all about a commit vs
your uncommitted changes, so having you say "--index" is just
silly. "git diff --cached" is just a shorthand for "git diff
--cached HEAD". Because --cached would make sense to no other
form of diff, its presense by definition means you are talking
about the one-tree form of diff i.e. compare a commit with your
uncommitted changes.
An example of a command that supports both is "git apply".
Actually it is an extreme case in that it allows "no index" form
of operation, so it has "git apply", "git apply --cached", and
"git apply --index". The --cached would only apply to index
without touching work tree, the --index would apply to both
index and work tree.
^ permalink raw reply
* Re: git-cvsserver commit trouble BUG+Work-around
From: Jan Wielemaker @ 2007-10-04 13:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0710041352480.4174@racer.site>
Hi Dscho,
On Thursday 04 October 2007 14:56, Johannes Schindelin wrote:
> On Thu, 4 Oct 2007, Jan Wielemaker wrote:
> > Indeed, the trouble is here: git-cvsserver, near line 1203:
> >
> > my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
> >
> > $state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
> > indeed gives no output. git show-ref -s refs/heads/master works just
> > fine.
>
> Ah! Did you do "CVSROOT=:ext:blablub cvs co HEAD"?
Yip ...
> You should "co master". The branches in git are the modules in cvs.
>
> HEAD is too volatile, you cannot make a proper module from it (imagine for
> example "git checkout next" where "next" is a branch, followed by "git
> checkout html", where "html" is another branch).
Ok. Pretty sure I got literal HEAD from one of the examples somewhere ...
Or, I've been blind all along. Anyway, the maintainer may consider giving
an error when trying to access HEAD as a module. Would have saved about
2 days work and its unlikely I'm the last victim :-(
Part of the two days is that during all the things I tried somehow
messed up with master too, so the one time I tried that it failed as
well :-(
Anyway, case closed. On with the testing ...
Thanks --- Jan
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Paolo Ciarrocchi @ 2007-10-04 13:10 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Git Mailing List
In-Reply-To: <20071004125641.GE15339@genesis.frugalware.org>
On 10/4/07, Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> > Why do we have the option "--cached" and not "--index"?
>
> according to glossary.txt, 'cache' is an obsolete for 'index'. probably
> this is the reason
>
> probably cache.h will be never renamed to index.h, i don't know if diff
> --cached will be ever renamed to diff --index
Believe me, for a GIT newbie git --cached is confusing.
That user started reading "A tutorial introduction to git (for version
1.5.1 or newer)",
after a cuple of minutes of reading he reached "Making changes" saw:
" You are now ready to commit. You can see what is about to be
committed using git-diff(1) with the —cached option:
$ git diff --cached "
$ git diff --index sound a lof more consistent with the general documentation.
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-10-04 13:06 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071004083304.GB17778@diana.vm.bytemark.co.uk>
On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
> 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 ...
Isn't a rollback log fairly easy to implement? Is there a single SHA
after each operation? If so just record the commands and the sha to
rollback.
I have also messed things up more than once using 'git merge linus'
instead of 'stg rebase linus'. Should 'git merge' have a check to see
if stg is active and refuse to run?
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Miklos Vajna @ 2007-10-04 12:56 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30710040527j61152b2dh1b073504ba19d490@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 375 bytes --]
On Thu, Oct 04, 2007 at 02:27:41PM +0200, Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> wrote:
> Why do we have the option "--cached" and not "--index"?
according to glossary.txt, 'cache' is an obsolete for 'index'. probably
this is the reason
probably cache.h will be never renamed to index.h, i don't know if diff
--cached will be ever renamed to diff --index
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Wincent Colaiuta @ 2007-10-04 12:54 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Git Mailing List
In-Reply-To: <4d8e3fd30710040527j61152b2dh1b073504ba19d490@mail.gmail.com>
El 4/10/2007, a las 14:27, Paolo Ciarrocchi escribió:
> Hi all,
> I'm having and interesting discussion with an happy mercurial users
> which started reading the git documentation. He raised aquestion that
> I'm not able to answer:
>
>> $ git diff --cached
>>
>> (Without —cached, git-diff(1) will show you any changes that you've
>> made but not yet added to the index.) You can also get a brief
>> summary
>> of the situation with git-status(1):
>
> Why do we have the option "--cached" and not "--index"?
I am not an "old timer", but I believe that it's because what we now
know as "the index" was original called "the cache". See:
<http://git.or.cz/gitwiki/GitHistory>
You're probably right that the option name is confusing, I guess
changing it to "--index" would be a good idea, continuing to support
"--cached" but marking it as deprecated before finally removing it at
some point in the future.
Cheers,
Wincent
^ permalink raw reply
* Re: git-cvsserver commit trouble BUG+Work-around
From: Johannes Schindelin @ 2007-10-04 12:56 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: git
In-Reply-To: <46823.146.50.26.20.1191496739.squirrel@webmail.science.uva.nl>
Hi,
On Thu, 4 Oct 2007, Jan Wielemaker wrote:
> Indeed, the trouble is here: git-cvsserver, near line 1203:
>
> my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
>
> $state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
> indeed gives no output. git show-ref -s refs/heads/master works just
> fine.
Ah! Did you do "CVSROOT=:ext:blablub cvs co HEAD"?
You should "co master". The branches in git are the modules in cvs.
HEAD is too volatile, you cannot make a proper module from it (imagine for
example "git checkout next" where "next" is a branch, followed by "git
checkout html", where "html" is another branch).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Johannes Schindelin @ 2007-10-04 12:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Martin Waitz, Andreas Ericsson, git
In-Reply-To: <7vir5nb89d.fsf@gitster.siamese.dyndns.org>
Hi,
On Thu, 4 Oct 2007, Junio C Hamano wrote:
> 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 do not know precisely about Cygwin (a quick test on my USB stick shows
that .git/config is created without the executable bit set), but in MSys
plain files which start with a she-bang are automatically +x, while all
other plain files are automatically -x (therefore this applies to
.git/config).
Given these findings, I fail to see what the patch should achieve, as
the first test (for -x) always succeeds...
Ciao,
Dscho
^ permalink raw reply
* Re: WIP: asciidoc replacement
From: Johannes Schindelin @ 2007-10-04 12:41 UTC (permalink / raw)
To: Sam Vilain; +Cc: Git Mailing List
In-Reply-To: <47046875.1050605@vilain.net>
Hi,
On Thu, 4 Oct 2007, Sam Vilain wrote:
> Given other people have answered some points, I'll answer the rest.
Thanks for your patient explanations!
Ciao,
Dscho
^ permalink raw reply
* A few usability question about git diff --cached
From: Paolo Ciarrocchi @ 2007-10-04 12:27 UTC (permalink / raw)
To: Git Mailing List
Hi all,
I'm having and interesting discussion with an happy mercurial users
which started reading the git documentation. He raised aquestion that
I'm not able to answer:
> $ git diff --cached
>
> (Without —cached, git-diff(1) will show you any changes that you've
> made but not yet added to the index.) You can also get a brief summary
> of the situation with git-status(1):
Why do we have the option "--cached" and not "--index"?
I believe that, just reading the documentation, is not very easy to
fully understand the role of the index and then we have an option
"--cached" that refers to the index.
Is it a good idea to add and document an option "--index" and remove
from the doc the option "--cached"?
Thanks.
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: stgit: lost all my patches again
From: Jon Smirl @ 2007-10-04 12:10 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Git Mailing List
In-Reply-To: <20071004083304.GB17778@diana.vm.bytemark.co.uk>
On 10/4/07, Karl Hasselström <kha@treskal.com> wrote:
> 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!
Must be the other way around then, the next nine patches didn't get
opened right. Their descriptions ended up in the right place but the
deltas all ended up in the first patch.
> > 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
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary (long)
From: Benoit SIGOURE @ 2007-10-04 12:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <8fe92b430710040212u332bb4e5yfa6c10b8236c6301@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1633 bytes --]
Hi Jakub,
nice work you've done there. Well done!
On Oct 4, 2007, at 11:12 AM, Jakub Narebski wrote:
> 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.
Once again (AFAIR this was already raised during one of the previous
summary) what's the link between GPLv2 and commercial support? You
seem to imply that because Git won't move to GPLv3, it's a good thing
for potential paid support, or something. I don't quite see how
GPLvX comes into play with commercial support. I'm not a license
expert though.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: git-cvsserver commit trouble BUG+Work-around
From: Jan Wielemaker @ 2007-10-04 11:18 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
In-Reply-To: <200710040927.03977.wielemak@science.uva.nl>
>> 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.
Finally getting at what is either a bug in git-show-ref or
git-cvsserver. I retried the whole lot using git-1.5.3.4:
<create initial repository>
% Created /home/jan/tmp/test/, added a file README with some text
% git-init
% git-add .
% git-commit
<create bare one for sharing>
% cd /home/git
% mkdir test.git
% cd test.git
% git --bare init --shared
% git --bare fetch /home/jan/tmp/test master:master
% git-config gitcvs.enabled 1
% git-config gitcvs.logfile `pwd`/cvs.log
% touch cvs.log
% chmod g+w cvs.log
% chgrp -R eculture .
<checkout>
% export CVS_SERVER=git-cvsserver
% cvs -d:ext:jan@localhost:/home/git/test.git co HEAD
% cd HEAD
% emacs README
% cvs commit -m test
cvs [commit aborted]: end of file from server (consult above messages if
any)
Same user, so we should not have permission rights. Indeed, the trouble
is here: git-cvsserver, near line 1203:
my $parenthash = `git show-ref -s refs/heads/$state->{module}`;
$state->{module} is -of course- HEAD. git show-ref -s refs/heads/HEAD
indeed gives no output. git show-ref -s refs/heads/master works just
fine. HEAD in the repo says:
gollem (test.git) 2_> cat HEAD
ref: refs/heads/master
I guess this link must be picked up by either git-cvsserver or
git-show-ref. Right? Anyway, if I add the line marked + to
git-cvsserver, cvs commit and cvs add operations appear to work (I
assume only if I work on the HEAD).
$ENV{GIT_INDEX_FILE} = $file_index;
+ $state->{module} = "master";
# Remember where the head was at the beginning.
Thanks for the comments. Really worrying is that such a big flaw can be
in stable git and remain their for at least 3 patch levels unnoticed.
Will someone take care of this and fix it properly in the right place
instead of this dirty hack?
Thanks --- Jan
^ permalink raw reply
* Re: [PATCH] git-init: don't base core.filemode on the ability to chmod.
From: Andreas Ericsson @ 2007-10-04 10:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Martin Waitz, git
In-Reply-To: <7vr6kbbdph.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> 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?
>
Nopes. I misread the first expression and simply assumed that "filemode"
should be != 0 for FS not supporting the x bit. I'd rename the variable
to bogus_fs and flip the logic, but I have no strong opinion either way.
>
> 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 */
> );
For "filemode=0 means FS doesn't support x-bit" it looks about right,
but kinda cumbersome to read.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 5/5] Use start_comand() in builtin-fetch-pack.c instead of explicit fork/exec.
From: Johannes Sixt @ 2007-10-04 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v8x6jb6of.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> 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.
Sure, will do this evening.
-- Hannes
^ permalink raw reply
* 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
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