* Re: gitweb tags feed, Re: New version announcements?
From: Pedro Melo @ 2008-07-24 16:51 UTC (permalink / raw)
To: Julian Phillips; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <Pine.LNX.4.64.0807241600190.7093@reaper.quantumfyre.co.uk>
Hi,
On Jul 24, 2008, at 4:04 PM, Julian Phillips wrote:
>> On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>>>
>>> Any way that a git-announce list could be created for security
>>> fixes and
>>> new releases? Or maybe an RSS feed on the website?
>
> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
Thanks Julian, did not knew these feeds.
You might want to look at the script that generates the announces
feed. It missed the 1.5.6.4 announcement.
http://article.gmane.org/gmane.comp.version-control.git/89148/
match=1.5.6.4
Best regards,
--
Pedro Melo
Blog: http://www.simplicidade.org/notes/
XMPP ID: melo@simplicidade.org
Use XMPP!
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-24 16:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vej5kfs0w.fsf@gitster.siamese.dyndns.org>
On Wed, Jul 23, 2008 at 10:07:43AM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > However, if you want to avoid CRs to _enter_ the repository, when you have
> > a lot of binary files tracked, you _do_ want to force all repositories to
> > crlf=input.
>
> If you are on a sane system, you do not even want to pay the price of
> conversion.
If you do not have CRLF then there will be no conversion, so you pay only
the price of check. The relative cost of that check obviously depends on
what other operations are. I believe that the worst case for this check
will be when there is no other operations, just re-reading files, so I
did:
# touch all files to force git re-read them...
git ls-files | xargs touch
time git status
Here is the average based on 3 attempts:
0.232s with autocrlf=false
0.265s with autocrlf=input (14% increase)
Of course, without touching files, git-status will take the same time in
both cases (about 0.026s in my testing), and touching all files not very
interesting from the practical point of view.
So, I decided to do something more practical, like applying 100 patches.
Here are my results:
false input
------ -------
7.409s 7.603s
7.592s 7.239s
7.617s 7.402s
------ -------
Average: 7.539s 7.415s
autocrlf=input turned out to be even slightly faster, but the difference
is not statistically significant.
So, though it is obvious that autocrlf=input clearly adds some overhead,
I believe it is negligable in most practical cases as there are much
more expensive operations. And you can always turn autocrlf off, if you
are sure that you never have files with the wrong line ending.
> Only people on systems with CRLF line endings should pay the
> price (because your aim is to convert on such systems).
Unfortunately, it is not so clearly cut. Some people may work on Unix
but share files with Windows using network shares or emails.
> Are we throwing
> that out of the window when the project decides to use gitattributes?
I am not sure that I understand your question. In any case, Dscho's
patch did not change the default, so it did not penalize anyone except
explicitly asked about that by setting crlf on some files. I would like
also to notice that setting crlf on some files (in contrast to unsetting
it!) is rarely necessary in practice if all users have sane settings for
autocrlf.
>
> How about setting autocrlf automatically on mingw/msys/cygwin versions,
> perhaps via templates or a patch to init-db? Would that, combined with
> user education, be a viable alternative?
Perhaps, it is good compromise for now, considering that Windows users
have most troubles with that... I really don't mind seeing 'input' as
default on other platforms, but I won't insist on that.
Dmitry
^ permalink raw reply
* Re: [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Mike Hommey @ 2008-07-24 16:54 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Christian Couder, git
In-Reply-To: <Pine.GSO.4.62.0807240233310.27074@harper.uchicago.edu>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=utf-8, Size: 878 bytes --]
On Thu, Jul 24, 2008 at 02:43:51AM -0500, Jonathan Nieder wrote:
> t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
> status when asked to list nonexistent files. Unfortunately,
> /bin/ls on Mac OS X 10.3 exits with exit code 0. So look at
> its output instead.
>
> Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
> ---
>
> Mike Hommey wrote:
>
> > On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> >> Le jeudi 24 juillet 2008, Jonathan Nieder a écrit :
> >>> - test_must_fail ls .git/BISECT_* &&
> >>> + echo .git/BISECT_* | test_must_fail grep BISECT_[^*] &&
> >>
> >> Perhaps the following is simpler:
> >>
> >> + test -z "$(ls .git/BISECT_*)" &&
> >
> > That is still a useless use of ls ;)
>
> It is much better than what I wrote, at least.
But could also be written with echo instead of ls.
Mike
^ permalink raw reply
* Re: git status in clean working dir
From: Jeff King @ 2008-07-24 16:54 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: Junio C Hamano, git, David Bremner
In-Reply-To: <D42305E3-82DA-46C1-B55F-74AD9AD48197@develooper.com>
On Wed, Jul 23, 2008 at 11:56:48PM -0700, Ask Bjørn Hansen wrote:
>> (2) Then why are we even allowing to configure the plumbing to page?
>
> I don't have an opinion on the the appropriateness of paging various
> commands, but to solve the problem of scripts getting tripped up by the
> paging, couldn't the plumping check if STDOUT is a tty and only do the
> paging if so?
>
> (In Perl "page_output(...) if $pager_configured and -t STDOUT")
We already do this, so "git status >/dev/null" produces the correct exit
code. But scripts don't necessarily redirect stdout.
-Peff
^ permalink raw reply
* [PATCH v2] document that git-tag can tag more than heads
From: Jonathan Nieder @ 2008-07-24 16:55 UTC (permalink / raw)
To: Kalle Olavi Niemitalo; +Cc: git
In-Reply-To: <87prp3652z.fsf@Astalo.kon.iki.fi>
After looking the git-tag manpage, someone on #git wondered how
to tag a commit that is not a branch head. This patch changes
the synopsis to say "<commit> | <object>" instead of "<head>" to
address his question.
Samuel Bronson had the idea of putting "<commit> | <object>"
for "<object>" because most tags point to commits (and for the
rest of the manpage, all tags point to commits).
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Kalle Olavi Niemitalo wrote:
> git-tag does not automatically dereference tag objects that
> point to a commit. So if you want to use "|", then it should be
> "<commit> | <object>".
Nice catch -- thanks.
Documentation/git-tag.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index b8dc88f..046ab35 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -9,7 +9,8 @@ git-tag - Create, list, delete or verify a tag object signed with GPG
SYNOPSIS
--------
[verse]
-'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>] <name> [<head>]
+'git tag' [-a | -s | -u <key-id>] [-f] [-m <msg> | -F <file>]
+ <name> [<commit> | <object>]
'git tag' -d <name>...
'git tag' [-n[<num>]] -l [<pattern>]
'git tag' -v <name>...
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: [PATCH 1/9] builtin-verify-tag.c: use parse_options()
From: Olivier Marin @ 2008-07-24 16:59 UTC (permalink / raw)
To: Michele Ballabio; +Cc: git, gitster
In-Reply-To: <1216849332-26813-2-git-send-email-barra_cuda@katamail.com>
Michele Ballabio a écrit :
>
> if (argc == 1)
> - usage(builtin_verify_tag_usage);
> + usage_with_options(builtin_verify_tag_usage, options);
It seems this is broken since the C rewrite: "git verify-tag -v" just do
nothing instead of printing usage message.
Moving the if() after parse_options() call with s/argc == 1/argc == 0/
should do the trick.
> - if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
> - verbose = 1;
> - i++;
> - }
> + argc = parse_options(argc, argv, options, builtin_verify_tag_usage, 0);
Olivier.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-24 17:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807241334340.8986@racer>
On Thu, Jul 24, 2008 at 01:39:34PM +0100, Johannes Schindelin wrote:
>
> Well, seems I will just continue shouting "why did you commit that
> CR-ridden file?" and get shouted back with "why does this §&%&%&!° Git
> tool not fix it for me automatically? Even _Subversion_ can do it."
Actually, no... With Subversion, if you do not have correct auto-props
then every newly added file will have incorrect end-of-lines. So, each
user has to manually add all possible text extensions in the auto-props
section of his/her subversion config file. In practice, it means that
with SVN you have far less problems with EOLs in first few days when
users just existing files, but then the problem reemerge every time when
someone adds a new file... So, it is not much better...
In constrast, Git provides automatic text detection and EOL conversion,
but it is not enabled where it should... at least, on Windows, and for
those who copies file directly from Windows through network shares or by
other means.
Dmitry
^ permalink raw reply
* Re: [PATCH 6/9] builtin-init-db.c: use parse_options()
From: Johannes Schindelin @ 2008-07-24 17:07 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4888AAB2.5050007@free.fr>
Hi,
On Thu, 24 Jul 2008, Olivier Marin wrote:
> Michele Ballabio a ??rit :
>
> > + OPT_BOOLEAN(0, "bare", &bare, "set up a bare repo"),
>
> s/set up/setup/
No. "setup" is a noun.
> > + { OPTION_CALLBACK, 0, "shared", &shared_repository,
> > + "type", "type of shared repository",
>
> What about "permissions", "setup a shared repository"?
>
> > + PARSE_OPT_OPTARG, parse_opt_shared_cb, PERM_GROUP },
>
> Are you sure the default value is really used here?
>
> Also, perhaps we can play it safer by avoiding changing "share_repository"
> directly.
I do not see how that would be any safer.
> $ git init -> shared_repository == PERM_UMASK
> $ git init --shared --no-shared -> shared_repository == 0
>
> It works because PERM_UMASK == 0, but it is a side effect. Don't you think?
Then the callback is wrong, too. I think, however, that it is by design,
and correct.
We rely on shared_repository == 0 for non-shared repositories _almost
everywhere_.
> > + OPT_BIT('q', "quiet", &flags, "be quiet", INIT_DB_QUIET),
>
> OPT__QUIET(&quiet),
>
> if (quiet)
> flags |= INIT_DB_QUIET;
>
> to use the same quiet option everywhere?
Why? Doesn't make it more readable, I think. I'd rather have 3 lines
less.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/9] builtin-verify-tag.c: use parse_options()
From: Johannes Schindelin @ 2008-07-24 17:08 UTC (permalink / raw)
To: Olivier Marin; +Cc: Michele Ballabio, git, gitster
In-Reply-To: <4888B4E3.9000504@free.fr>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 751 bytes --]
Hi,
On Thu, 24 Jul 2008, Olivier Marin wrote:
> Michele Ballabio a écrit :
> >
> > if (argc == 1)
> > - usage(builtin_verify_tag_usage);
> > + usage_with_options(builtin_verify_tag_usage, options);
>
> It seems this is broken since the C rewrite: "git verify-tag -v" just do
> nothing instead of printing usage message.
>
> Moving the if() after parse_options() call with s/argc == 1/argc == 0/
> should do the trick.
That would be a bugfix. As such, it belongs into a different commit.
Care to provide a patch?
> > - if (!strcmp(argv[i], "-v") || !strcmp(argv[i], "--verbose")) {
> > - verbose = 1;
> > - i++;
> > - }
> > + argc = parse_options(argc, argv, options, builtin_verify_tag_usage, 0);
Why did you quote this?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-24 17:14 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, git
In-Reply-To: <20080724165335.GW2925@dpotapov.dyndns.org>
Hi,
On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> If you do not have CRLF then there will be no conversion, so you pay
> only the price of check. The relative cost of that check obviously
> depends on what other operations are. I believe that the worst case for
> this check will be when there is no other operations, just re-reading
> files, so I did:
>
> # touch all files to force git re-read them...
> git ls-files | xargs touch
> time git status
>
> Here is the average based on 3 attempts:
> 0.232s with autocrlf=false
> 0.265s with autocrlf=input (14% increase)
And you tested... on git.git? One of the smallest serious Git users?
If you want to come close to the hard cases (that you would punish with
setting autocrlf = input, not yourself of course), test _at least_ the
Linux kernel.
To come closer you should test on OpenOffice.org or KDE.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 01/12] git-grep: read config
From: Jeff King @ 2008-07-24 17:15 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145535.GA29053@laptop>
On Wed, Jul 23, 2008 at 09:55:35PM +0700, Nguyễn Thái Ngọc Duy wrote:
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
The commit message is a bit lacking...what config are we interested in?
-Peff
^ permalink raw reply
* Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Jeff King @ 2008-07-24 17:19 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git
In-Reply-To: <20080723145718.GA29134@laptop>
On Wed, Jul 23, 2008 at 09:57:18PM +0700, Nguyễn Thái Ngọc Duy wrote:
> + if (option_sparse_prefix) {
> + git_config_set("core.sparsecheckout", option_sparse_prefix);
> + set_sparse_prefix(option_sparse_prefix);
> + }
> +
As a user, I would expect "sparse clone" to also be sparse on the
fetching. That is, to not even bother fetching tree objects that we are
not going to check out. But that is a whole other can of worms from
local sparseness, so I think it is worth saving for a different series.
So instead I would suggest that this be mentioned in the documentation
for --path, but there doesn't seem to be any.
-Peff
^ permalink raw reply
* Re: gitweb tags feed, Re: New version announcements?
From: Julian Phillips @ 2008-07-24 17:25 UTC (permalink / raw)
To: Pedro Melo; +Cc: Petr Baudis, Jordi Bunster, git, gitster
In-Reply-To: <B7201433-1725-4C3A-85D6-4C036635FD17@simplicidade.org>
On Thu, 24 Jul 2008, Pedro Melo wrote:
> Hi,
>
> On Jul 24, 2008, at 4:04 PM, Julian Phillips wrote:
>> > On Thu, Jul 24, 2008 at 10:38:24AM -0400, Jordi Bunster wrote:
>> > >
>> > > Any way that a git-announce list could be created for security fixes
>> > > and
>> > > new releases? Or maybe an RSS feed on the website?
>>
>> An RSS feed already exists, have a look at http://gitrss.q42.co.uk/.
>
> Thanks Julian, did not knew these feeds.
>
> You might want to look at the script that generates the announces feed. It
> missed the 1.5.6.4 announcement.
>
> http://article.gmane.org/gmane.comp.version-control.git/89148/match=1.5.6.4
Ah ... oops. Some stuff got broken during a system upgrade on the 20th,
and I seem to have missed that mail when trying to fill in the gap (due to
a similar breakage in my personal email system I didn't know it had gone
out :(). Hopefully that won't happen again.
Should be there now. Thanks. :)
--
Julian
---
The advertisement is the most truthful part of a newspaper.
-- Thomas Jefferson
^ permalink raw reply
* [PATCH] index-pack: correctly initialize appended objects
From: Johannes Schindelin @ 2008-07-24 17:32 UTC (permalink / raw)
To: Nicolas Pitre, spearce; +Cc: git, gitster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1259 bytes --]
From: Björn Steinbrink <B.Steinbrink@gmx.de>
When index-pack completes a thin pack it appends objects to the pack.
Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
resolving deltas) such an object can be pruned in case of memory
pressure.
To be able to re-read the object later, a few more fields have to be set.
Noticed by Pierre Habouzit.
Hopefully-signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Hopefully-reviewed-and-signed-off-by: Nicolas Pitre <nico@cam.org>,
--
This was probably missed in the flurry of patches, scratched
patches, and new patches.
Nico could you have a quick look? (I would ask Shawn, but I know
that he is pretty busy with real world issues.)
diff --git a/index-pack.c b/index-pack.c
index ac20a46..33ba8ef 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -699,6 +699,9 @@ static struct object_entry *append_obj_to_pack(
write_or_die(output_fd, header, n);
obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
+ obj[0].hdr_size = n;
+ obj[0].type = type;
+ obj[0].size = size;
obj[1].idx.offset = obj[0].idx.offset + n;
obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
hashcpy(obj->idx.sha1, sha1);
^ permalink raw reply related
* sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Johannes Schindelin @ 2008-07-24 17:41 UTC (permalink / raw)
To: Jeff King; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20080724171952.GB21043@sigill.intra.peff.net>
Hi,
On Thu, 24 Jul 2008, Jeff King wrote:
> As a user, I would expect "sparse clone" to also be sparse on the
> fetching. That is, to not even bother fetching tree objects that we are
> not going to check out. But that is a whole other can of worms from
> local sparseness, so I think it is worth saving for a different series.
I think this is not even worth of a series. Sure, it would have benefits
for those who want sparse checkouts. But it comes for a high price on
everyone else:
- security issues (you'd need to open the git protocol to give you
something else than a ref, _including_ refs that were deleted)
- performance issues (the server would have to do a lot more, faking
commits, or in the alternative serving a gazillion more sessions if the
client does the reconstruction)
... and I am sure there are tons more issues.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] t6030 (bisect): work around Mac OS X "ls"
From: Johannes Schindelin @ 2008-07-24 17:44 UTC (permalink / raw)
To: Mike Hommey; +Cc: Jonathan Nieder, Christian Couder, git
In-Reply-To: <20080724165434.GA26660@glandium.org>
Hi,
On Thu, 24 Jul 2008, Mike Hommey wrote:
> On Thu, Jul 24, 2008 at 02:43:51AM -0500, Jonathan Nieder wrote:
>
> > Mike Hommey wrote:
> >
> > > On Thu, Jul 24, 2008 at 07:57:26AM +0200, Christian Couder wrote:
> > >
> > >> + test -z "$(ls .git/BISECT_*)" &&
> > >
> > > That is still a useless use of ls ;)
> >
> > It is much better than what I wrote, at least.
>
> But could also be written with echo instead of ls.
Sure, but then it looks uglier:
test ".git/BISECT_*" = "$(echo .git/BISECT_*)" &&
and it is much easier to hide a typo there.
And now the big question: is it performance critical? Or is obvious
correctness the highest goal here?
Hth,
Dscho
^ permalink raw reply
* [PATCH v3] t6030 (bisect): work around Mac OS X "ls"
From: Jonathan Nieder @ 2008-07-24 17:51 UTC (permalink / raw)
To: Mike Hommey; +Cc: Christian Couder, git
In-Reply-To: <20080724165434.GA26660@glandium.org>
t6030-bisect-porcelain.sh relies on "ls" exiting with nonzero
status when asked to list nonexistent files. Unfortunately,
/bin/ls on Mac OS X 10.3 exits with exit code 0. So use "echo"
instead.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Mike Hommey wrote:
>>>> + test -z "$(ls .git/BISECT_*)" &&
>>> That is still a useless use of ls ;)
>> It is much better than what I wrote, at least.
> But could also be written with echo instead of ls.
How about this? (The echo is necessary because the argument
to a case statement does not undergo filename expansion.)
t/t6030-bisect-porcelain.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 0626544..b6841fe 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -76,7 +76,7 @@ test_expect_success 'bisect fails if given any junk instead of revs' '
test_must_fail git bisect start foo $HASH1 -- &&
test_must_fail git bisect start $HASH4 $HASH1 bar -- &&
test -z "$(git for-each-ref "refs/bisect/*")" &&
- test_must_fail ls .git/BISECT_* &&
+ case $(echo .git/BISECT_*) in *\*) ;; *) false ;; esac &&
git bisect start &&
test_must_fail git bisect good foo $HASH1 &&
test_must_fail git bisect good $HASH1 bar &&
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: [PATCH] Respect crlf attribute even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-24 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807241811580.8986@racer>
On Thu, Jul 24, 2008 at 06:14:09PM +0100, Johannes Schindelin wrote:
> On Thu, 24 Jul 2008, Dmitry Potapov wrote:
> >
> > Here is the average based on 3 attempts:
> > 0.232s with autocrlf=false
> > 0.265s with autocrlf=input (14% increase)
>
> And you tested... on git.git? One of the smallest serious Git users?
If you take a huge repo, you are going to be bound by disk IO unless
huge amount memory, so all files reside in the filesystem cache.
>
> If you want to come close to the hard cases (that you would punish with
> setting autocrlf = input, not yourself of course), test _at least_ the
> Linux kernel.
false input
6.913s 8.426s
6.922s 8.337s
6.969s 8.335s
6.975s 8.386s
6.939s 8.435s
6.954s 8.320s
autocrlf=input takes 20% more than autocrlf=false, which is rather
strange, because I clearly saw some disk activity... so I expected
it to be less...
In any case, this test is rather artificial, and the real one should
be is of course applying patches... Maybe I will try that later...
Dmitry
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Dmitry Potapov @ 2008-07-24 17:57 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Stephan Beyer
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> Is there some channel that I have forgot about?
If the start of this survey can be timed to release 1.6.0 then the
announce about Git 1.6.0 release may also contain reference to that
survey, and because release announcements are usually widely distributed
by online magazines such as LinuxToday and LWN, anyone who is interested
in Git will learn about this survey too.
Dmitry
^ permalink raw reply
* Re: [RFC PATCH 00/12] Sparse checkout
From: James Pickens @ 2008-07-24 17:59 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0807240200x10a6a267h4c37e4566da967ba@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds <at> gmail.com> writes:
> This one is difficult (and may probably produce more intrusive patch).
> Let's see what I can do.
This is not a high priority for me, so if the added
difficulty/intrusiveness means it would take longer for the sparse
checkout capability to make it into mainline git, then I would drop this
request, or at least delay it until some later time.
> > Second, I would want a capability to checkout and release directories
> > incrementally, similar to how we do it in cvs. For example, I might do
> > the following in cvs:
>
> You can do that with "git checkout --path" (non-recursive checkout aside):
>
> $ git checkout --path=A # checkout full A
> $ git checkout --path=A/B1/C1 # no, limit to A/B1/C1 only
> $ git checkout --path=A/B1/C1:A/B2 # extend to A/B2 too
My point was not that incremental checkout is impossible, just that it
would be easier if I didn't have to re-type the full path list again.
Suppose I had 9 directories (A/B1 through A/B9) in my sparse checkout,
and I wanted to add a 10th directory (A/B10). It would be much easier
to type something like
$ cd A
$ git checkout B10
instead of
$ git checkout --path=A/B1:A/B2:A/B3:A/B4:A/B5:A/B6:A/B7:A/B8:A/B9:A/B10
Another thing I thought of, which I'm not sure if it's sensible or not,
is to make sparse checkout a persistent branch attribute by creating a
.gitpaths (or whatever) file containing a list of directories that
should be checked out. This would be analogous to the .gitmodules file.
The .gitpaths file could then be checked in, and applied automatically
any time the user checks out a branch containing such file. This is
just an idea for discussion, not a feature request.
James
^ permalink raw reply
* Re: [PATCH] index-pack: correctly initialize appended objects
From: Björn Steinbrink @ 2008-07-24 18:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nicolas Pitre, spearce, git, gitster
In-Reply-To: <alpine.DEB.1.00.0807241821440.8986@racer>
On 2008.07.24 18:32:00 +0100, Johannes Schindelin wrote:
>
> From: Björn Steinbrink <B.Steinbrink@gmx.de>
>
> When index-pack completes a thin pack it appends objects to the pack.
> Since the commit 92392b4(index-pack: Honor core.deltaBaseCacheLimit when
> resolving deltas) such an object can be pruned in case of memory
> pressure.
>
> To be able to re-read the object later, a few more fields have to be set.
Ah, thanks a lot! I tried to come up with a sane commit message
yesterday but totally failed, and then after a night of sneezing, I had
forgotten about it. And I wouldn't have managed to write an equally good
message anyway ;-)
> Noticed by Pierre Habouzit.
>
> Hopefully-signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Sure!
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Thanks,
Björn
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Dmitry Potapov @ 2008-07-24 18:08 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200807232349.42244.jnareb@gmail.com>
On Wed, Jul 23, 2008 at 11:49:41PM +0200, Jakub Narebski wrote:
> On Wed, 23 Jul 2008, Dmitry Potapov wrote:
> > On Wed, Jul 23, 2008 at 03:25:03AM +0200, Jakub Narebski wrote:
> > >
> > > 02. What is your preferred non-programming language?
> > > (or) What is the language you want computer communicate with you?
> >
> > IMHO, the later wording of the question is much better.
>
> First just satisfies demographic curiosity. Second is more question
> about internationalization (i18n).
I think demographic is largely covered by the first question about
country. As to i18n, I don't think it is fully covered just by the
question about one's language preference to communicate with computer
(which is probably is more correctly to call localization). Possible
questions related to i18n are:
- Do you use file names with non-ASCII characters?
- Do you use text files with non-ASCII characters?
- Do you (or members of your team) use computers with different
character sets and have to deal with non-ASCII characters?
But I guess we do not want to have so many questions. So, maybe
something simple instead:
- Are you satisfied with support for non-ASCII characters in Git?
> Should "What version do you use now?" be multiple choice (using git
> on more than one machine / operating system)?
I think we already have another question about what OS one uses.
So I believe it should be only version number here.
> What should be possible
> choices for "How long do you use git?"? Perhaps.
>
> 10. How long do you use git?
> (single choice)
> - never/few days/few weeks/month/few months/year/few years/
> from beginning/I wrote it(*)
> + (*) just kidding ;-)
I would rather use numbers like that:
never
less than month
1-3 months
3-6 months
6-12 months
1-2 year
more than 2 years
from the beginning
Dmitry
^ permalink raw reply
* Re: [PATCH v3] t6030 (bisect): work around Mac OS X "ls"
From: Jonathan Nieder @ 2008-07-24 18:16 UTC (permalink / raw)
To: Mike Hommey; +Cc: Christian Couder, git
In-Reply-To: <Pine.GSO.4.62.0807241233190.16518@harper.uchicago.edu>
Jonathan Nieder wrote:
> - test_must_fail ls .git/BISECT_* &&
> + case $(echo .git/BISECT_*) in *\*) ;; *) false ;; esac &&
Actually, if we want to go that route, I prefer the version Dscho gave.
So please ignore my patch v3; I'd rather people choose between
Christian's and Dscho's suggestions.
Personally, without knowing how much time avoiding the ls saves, I
am not sure which is best. Certainly the version with "ls" is clearer,
which is most important; but if the time savings (of avoiding such
constructs generally) are significant, then that is very much worthwhile
- a faster test suite can be run more often.
Jonathan
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-24 18:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: git
In-Reply-To: <48889591.9020208@freescale.com>
On Thu, 24 July 2008, Jon Loeliger wrote:
> Jakub Narebski wrote:
> >
> > About you
> >
> > 01. What country are you in?
> > 02. What is your preferred non-programming language?
> > (or) What is the language you want computer communicate with you?
>
> How about: What is your preferred natural language?
Perhaps it is a better formulation. I am not native English speaker.
(But so would be some people who would answer this survey).
The problem with this question is that people does not understand it,
and either do not answer or answer for example with computer language
(C, Perl, or something like that). For 2007 survey, when the question
was formulated as "02. What is your preferred non-programming language?"
there were 37 invalid responses (computer language), and 4 "not
understand" responses out of 662 people who answered this question.
On of the goals (besides curiosity about demographics) of this question
is to get to know if Git core should provide infrastructure for
translating messages, in addition to what already exists for git-gui
and gitk. But as currently there are no other questions about l10n
and i18n perhaps it would be better to simply remove this question.
> > 03. How old are you (in years)?
> > (free form, integer)
> > 04. Which programming languages you are proficient with?
>
> Perhaps:
> With which programming languages are you proficient?
Again: I am not native English speaker.
> > Getting started with GIT
> >
> > 05. How did you hear about Git?
> > (single choice?, in 2007 it was free-form)
> > - Linux kernel news (LKML, LWN, KernelTrap, KernelTraffic,...),
> > news site or magazine, blog entry, some project uses it,
> > presentation or seminar (real life, not on-line),
> > SCM research, IRC, mailing list, other Internet,
> > other off-line, other(*)
> > + the problem is with having not very long list (not too many
> > choices), but spanning all possibilities.
>
> So go more general? Don't specify actual news (web)sites.
I didn't mean here enumerating actual news (web)sites, but to provide
examples.
> Don't forge that there is a whole raft of Ruby-n-rails folks who
> are embracing Git these days too. They have their own whole 'nuther
> set of mailing lists, websites, (news) lists, etc.
>
> > + is this question interesting/important to have in survey?
>
> Look to the history to answer this question. Did we really
> learn anything from the earlier surveys by this question?
> Maybe it would make more sense to get a feel for which general
> camp led them to Git? That is, did they come from the Kernel
> side of the world, or Ruby-on-Rails, or self-exploration, etc.
That is what I think we want to find through this question.
Unfortunately I have found about Git by reading KernelTraffic
and later KernelTrap during the whole "BitKeeper fiasco"; I have
next to no idea about how other people have heard about Git.
Help!?
There is other side to this question, _if_ we were some company, or/and
_if_ we were concerned about making Git more popular, namely to
identify the paces where "advertising" would make most impact.
> > 06. Did you find GIT easy to learn?
> > - very easy/easy/reasonably/hard/very hard
>
> But that has to be contrasted with their _current_ notion
> in order to know if they make progress or not. If the
> difficulty persists, we're in trouble. If it is just a
> steep learning curve, we might be able to address that.
>
> So maybe some variant questions like:
> How do you find it now (after some use)?
> same [very easy..very hard] scale
> How long have you been using Git?
The question is here to either dispel the myth that Git is hard to
learn, or find that we have steep learning curve and that we should
perhaps do something about it.
> Rate your own Git proficiency:
> [noob, casual, I survive, everyday use,
> I answer questions from others,
> I use plumbing in scripts daily,
> Power User, Godly, I am Junio]
Good idea about question about Git proficiency.
> > 07. What helped you most in learning to use it?
> > (free form question)
> > 08. What did you find hardest in learning Git?
> > What did you find harderst in using Git?
> > (free form question)
> > 09. When did you start using git? From which version?
> > - pre 1.0, 1.0, 1.1, 1.2, 1.3, 1.4, 1.5
>
> It's likely that most people don't know the specific answer
> to that question and will just guess, if anything. It is
> also semi-subject to time-slide as old installs are made on
> different distributions [*cough*] Debian. I think the question
> "How long have you been using Git?" Might be more easily
> answered and show better data. (Adoption curve.)
True. I think "How long have you been using Git?" with log-like
multiple choice scale: few days/few weeks/month/few months/year/few
years would be better idea.
On the other hand knowing which version someone started his/her
"Git adventure" would help to find probable causes where some of ideas
about git were already corrected in later versions...
> > + might be important when checking "what did you find
> > hardest" etc.
> > + perhaps we should ask in addition to this question, or in
> > place of this question (replacing it) what git version one
> > uses; it should be multiple choice, and allow 'master',
> > 'next', 'pu', 'dirty (with own modifications)' versions
> > in addition.
It would be next (additional) question, probably multiple choice, and
easy to check out with "git version" or "git --version" command.
> > Other SCMs (shortened compared with 2007 survey)
> >
> > 10. What other SCM did or do you use?
> > (zero or more: multiple choice)
> > - CVS, Subversion, GNU Arch or arch clone (ArX, tla, ...),
> > Bazaar-NG, Darcs, Mercurial, Monotone, SVK, AccuRev,
> > Perforce, BitKeeper, ClearCase, MS Visual Source Safe,
> > MS Visual Studio Team System, custom, other(*)
>
> What? No SCCS?
Hmmm... SCCS got 18 out of 654 responses, only one less than SVK.
I'd add it to the list of choices for this question, then.
> > 10b.If you selected other above, what SCM it was?
>
> s/it was/was it/
>
> > (free form)
> > 11. Why did you choose Git? (if you use Git)
>
> That's a bit vague... First, maybe they didn't choose Git.
> Maybe they are on a project where it was mandated.
> So, Why did they choose Git for _what_?
>
> Are we trying to ask "Why did you decide to use Git?" ?
Yes, that was I wanted to ask. "Why do you use Git? (if you do use it)".
> > What do you like about using Git?
> > (free form, not to be tabulated)
>
> Presuming they do... :-) So, maybe add:
>
> I enjoy using Git: [-5 .. 0 .. +5]
> Git satisfies my use cases: [-5 .. 0 .. +5]
> I prefer Git over CVS/SVN: [-5 .. 0 .. +5]
>
> Or so...
I'm not sure if it wouldn't be more interesting to have free-form here.
I think we would get quite a number of unique and non-obvious answers.
Besides the above form depends on survey site to be able to create such
matrix of responses...
> > How you use Git
> >
> > 13. Do you use Git for work, unpaid projects, or both?
> > (single choice)
> > - work/unpaid projects/both
>
> But there are other uses too. I use it for personal crap
> like my Brewing Log. Sure, it is an "unpaid project", but
> that's not very useful information. Maybe it would make
> sense to expand this question into, say, 10 choices that
> we feel are likely uses cases and see what the actual
> demographics are. That is, the two-part-with-waffle isn't
> that informative.
>
> Maybe:
> I use Git for: [check all that apply]
> Work projects
> Personal data
> Unpaid Open Source Development
> Sharing Data with my Niece
> Maintaining my Website
> Backending my Blog
> etc.
Very good idea. This way we can share this question with question about
kind of data one uses Git for.
By the way, perhaps we should split "Work projects" into "Work projects"
and "Work projects (private git)" to distinguish between cases where Git
is used at work, and where you use Git privately (for example via
git-svn, or git-p4) to interact with other SCM that is used at work.
> My point here is that we can learn what Git is being
> used for, and ....
>
> Although for some reason I can't yet, I would
> really like to use Git for:
> My Wordpress backend
> Maintaining my {pr0n,mp3} Collection
> Work projects
> Sharing data with my boss
> etc.
>
> That would give us a sense of direction possibly.
> It might provide a notion as to what people are wanting
> to do, but for some reason find it hard to pull off.
> That is, help us identify use-cases that are being limited
> but would otherwise be adoptive.
Hmmmm...
> > 18. Which (main) git web interface do you use for your projects?
> > (zero or more: multiple choice)
> > - gitweb, cgit, wit (Ruby), git-php, viewgit (PHP), other
> > + should there be a question about web server (Apache,
> > IIS, webrick, LigHTTPd, ...) used to host git web interface?
>
> Probably not. Most people might not even know.
I can agree with that.
On the other hand the purpose of this question was to get a list
of most popular servers to put example configuration for hosting git
repositories via HTTP(S) protocol, and for setting up gitweb.
> > What you think of Git
> >
> > 24. If you want to see Git more widely used, what do you
> > think we could do to make this happen?
> > + Is this question necessary/useful? Do we _need_
> > wider adoption?
>
> Hmmm. See some ramblings of mine above too... :-)
What ramblings were they?
> >
> > Changes in Git (since year ago, or since you started using it)
> >
> > 26. How do you compare current version with version from
> > year ago?
> > - current version is: better/worse/no changes
The list of possible answers should (just in case, because you can
simply not answer this question, although some would not know this)
also "I don't know, I didn't use Git for a year".
> More fine detail needed there? To help identify what people
> think have improved and what has not yet improved?
>
> Since you started using Git, rate how the following
> functional areas have/have-not improved:
> The User Interface [-5 .. 0 .. +5]
> The command line interface [-5 .. 0 .. +5]
> The intuitive behavior [-5 .. 0 .. +5]
> The overall experience
> The behavior of 'fetch'
> The behavior of "git log'
> The config file
> etc.
This of course depends on web survey site allowing such feature
in survey.
> A -5 means it still sucks or got worse, 0 is neutral
> or no opinion, and +5 means it rocks or got better.
> This would give us direct feedback indicating if we,
> as a whole, are headed in the right direction with our
> development efforts. It will also directly tell us
> which features people find still suck.
>
> We should attempt to get direct feedback on many Git features.
The trouble of course would be with coming up with the "laundry list" of
features people did or can have a problem with.
> > Documentation
> >
> > 31. Do you contribute to Git wiki?
> > - yes/no/only corrections or spam removal
>
> If "no", why not?
Good idea.
> [Wikis suck, I don't know the answers, no time...]
[We have a wiki???] ;-)
> > 32. Do you find Git's on-line help (homepage, documentation)
> > useful?
> > - yes/no/somewhat
>
> Confusing.
I think it would fall in "somewhat" category I think.
> > Getting help, staying in touch
> >
> > 42. Do you find traffic levels on Git mailing list OK.
> > - yes/no? (optional)
>
> I find the mailing list traffic level to be:
> [too low, OK, just right, tolerable, intolerable,
> a bit high, absurdly high]
Good idea of expanding the list of answers, otherwise it is hard to
answer this question. Although perceived signal to noise ratio might
be more important than bare traffic.
> > Open forum
> >
> > 46. What other comments or suggestions do you have that are not
> > covered by the questions above?
> > (free form)
> >
>
> I've got to ... ramble on,
:-DDDDD
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: sparse fetch, was Re: [PATCH 08/12] git-clone: support --path to do sparse clone
From: Jeff King @ 2008-07-24 18:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <alpine.DEB.1.00.0807241837441.8986@racer>
On Thu, Jul 24, 2008 at 06:41:03PM +0100, Johannes Schindelin wrote:
> > As a user, I would expect "sparse clone" to also be sparse on the
> > fetching. That is, to not even bother fetching tree objects that we are
> > not going to check out. But that is a whole other can of worms from
> > local sparseness, so I think it is worth saving for a different series.
>
> I think this is not even worth of a series. Sure, it would have benefits
> for those who want sparse checkouts. But it comes for a high price on
> everyone else:
I agree there are a lot of issues. I am just thinking of the person who
said they had a >100G repository. But I am also not volunteering to do
it, so I will let somebody who really cares about it try to defend the
idea.
-Peff
^ 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