* [PATCH (take 4)] gitweb: Use File::Find::find in git_get_projects_list
From: Jakub Narebski @ 2006-09-14 20:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <7vejue2omq.fsf@assigned-by-dhcp.cox.net>
Earlier code to get list of projects when $projects_list is a
directory (e.g. when it is equal to $projectroot) had a hardcoded flat
(one level) list of directories. Allow for projects to be in
subdirectories also for $projects_list being a directory by using
File::Find.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 30 ++++++++++++++++++++----------
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c3544dd..25383bc 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -715,16 +715,26 @@ sub git_get_projects_list {
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
- opendir my ($dh), $dir or return undef;
- while (my $dir = readdir($dh)) {
- if (-e "$projectroot/$dir/HEAD") {
- my $pr = {
- path => $dir,
- };
- push @list, $pr
- }
- }
- closedir($dh);
+ my $pfxlen = length("$dir");
+
+ File::Find::find({
+ follow_fast => 1, # follow symbolic links
+ dangling_symlinks => 0, # ignore dangling symlinks, silently
+ wanted => sub {
+ # skip current directory
+ return if (m!^[/.]$!);
+ # only directories can be git repositories
+ return unless (-d $_);
+
+ my $subdir = substr($File::Find::name, $pfxlen + 1);
+ # we check related file in $projectroot
+ if (-e "$projectroot/$subdir/HEAD") {
+ push @list, { path => $subdir };
+ $File::Find::prune = 1;
+ }
+ },
+ }, "$dir");
+
} elsif (-f $projects_list) {
# read from file(url-encoded):
# 'git%2Fgit.git Linus+Torvalds'
--
1.4.2
^ permalink raw reply related
* Re: [PATCH (take 3)] gitweb: Use File::Find::find in git_get_projects_list
From: Junio C Hamano @ 2006-09-14 20:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200609142134.33725.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> + wanted => sub {
> + # skip current directory
> + return if (m!^/|.|..$!);
Huh?
(1) Did you mean to say "\." (not any single character but
literally dot)?
(2) how does the alternatives within m{} construct bind (iow,
please be gentle to the readers)? Do you mean
return if (/^\/(?:\.|\.\.)$/)
in other words,
return if (/^\/\.$/ || /^\/\.\.$/)
in other words,
return if (/^\/\.{1,2}/)
???
^ permalink raw reply
* Re: Notes on supporting Git operations in/on partial Working Directories
From: A Large Angry SCM @ 2006-09-14 20:08 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060914192119.GC10556@spearce.org>
Shawn Pearce wrote:
> A Large Angry SCM <gitzilla@gmail.com> wrote:
>> The contents of the index file still reflect the full tree but flag each
>> object (file or symlink) separately as part of the checkout or not. The
>> WD_Prefix string is so that a partial checkout consisting of only
>> objects somewhere in the a/b/c/d/ tree can be found in the working
>> directory without the a/b/c/d/ prefix to the path of the object.
>
> Why not just load a partial index?
>
> If we only want "a/b/c/d" subtree then only load that into the index.
> At git-write-tree time return the new root tree by loading the tree
> of the current `HEAD` commit and walking down to a/b/c/d, updating
> that with the tree from the index, then walking back updating each
> node you recursed down through. Finally output the new root tree.
>
> The advantage is that if you have a subtree checked out you aren't
> working with the entire massive index.
I was looking for minimal changes to the index and associated code.
Either way works.
> But how does this let the user checkout and work on the 10 top
> level directories at once and perform an atomic commit to all
> of them, but not checkout the other 100+ top level directories?
> As I recall this was desired in the Mozilla project for example.
That's a partial working working directory by my definition so it would
work. How it's specified on the command line is TBD.
It's desired by a lot of very modular projects.
>> [*3*] Possibly split the index up by directory and store the parts in
>> the working directory. An index "distributed" in this way would have
>> a "natural" cache-tree built in and (finally) be able support empty
>> directories.
>
> Please, no. On a project with a large number of directories
> operations like git-write-tree would take a longer time to scan the
> index and generate the new trees. I unfortunately work on such
> projects as its common for Java applications to be very deeply
> nested and large projects have a *lot* of directories.
Directory trees without any changes might actually be less expensive to
work with using the split index since you could ignore all of the
unchanged entries easily.
^ permalink raw reply
* Re: nightly tarballs of git
From: Junio C Hamano @ 2006-09-14 20:06 UTC (permalink / raw)
To: Dave Jones; +Cc: git
In-Reply-To: <20060914193616.GA32735@redhat.com>
Dave Jones <davej@redhat.com> writes:
> DATE=`date +%Y-%m-%d`
>
> PROJ="git"
> cd ~/git-trees
> if [ -d $PROJ ]; then
> cd $PROJ
> git pull -n
> else
> git clone -q git://git.kernel.org/pub/scm/git/git.git
> cd $PROJ
> fi
> snap=git-snapshot-$(date +"%Y%m%d")
> git-tar-tree HEAD $snap | gzip -9 > $PROJ-$DATE.tar.gz
If you are using git-tar-tree (which by the way _is_ the right
thing to do) and if you are just taking an upstream snapshot
without doing your own development (which also is the case
here), then you do not even need a working tree in the directory
this script runs. It would save your disk space and time to
check out the updated working tree files.
Perhaps...
#!/bin/sh
URL=git://git.kernel.org/pub/scm/git/git.git
PROJ=git
cd ~/git-trees
if test -d "$PROJ"
then
cd "$PROJ" && git fetch
else
git clone -q -n "$URL" "$PROJ" && cd "$PROJ"
fi || {
echo >&2 Something wicked happend.
exit $?
}
snap=git-snapshot-$(date +"%Y%m%d")
git-tar-tree origin $snap | gzip -9 > $PROJ-$DATE.tar.gz
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Use File::Find::find in git_get_projects_list
From: Junio C Hamano @ 2006-09-14 19:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eec9lt$7ll$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Gaah, the code spews quite a lot of warnings as of now.
>
> Variable "$pfxlen" will not stay shared at gitweb.perl line 724.
> Variable "@list" will not stay shared at gitweb.perl line 727.
> ...
Thanks for an early warning. Will not apply that one and
instead will wait for updates.
^ permalink raw reply
* Re: Notes on supporting Git operations in/on partial Working Directories
From: Junio C Hamano @ 2006-09-14 19:50 UTC (permalink / raw)
To: gitzilla; +Cc: git
In-Reply-To: <4509A7EC.9090805@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> The minimum required changes[*1*][*2*][*3*] to the index file to support
> partial checkouts are:
>
> 1) the addition of WD_Prefix string to hold the common path prefix of
> all objects in the working directory. For a full checkout, the WD_Prefix
> string would be empty.
>
> 2) A (new) flag for each entry in the index indicating whether or not
> the object is in the partial checkout.
>
> The contents of the index file still reflect the full tree but flag each
> object (file or symlink) separately as part of the checkout or not. The
> WD_Prefix string is so that a partial checkout consisting of only
> objects somewhere in the a/b/c/d/ tree can be found in the working
> directory without the a/b/c/d/ prefix to the path of the object.
>
> All the Git commands that use the index file will need to be changed to
> support this but the transfer protocols do not need to change.
While this may be a good start, you need a lot more than this if
you want to do (1) and (2):
The tree object contained by a commit is by definition a full
tree snapshot, so if you want to do a WD_Prefix, you somehow
need a way to come up with the final tree that is a combination
of what write-tree would write out from such a partial index
(i.e. an index that describes only a subdirectory) and the rest
of the tree from the current HEAD. I think you can more or less
do this change to Porcelain using today's git core. The
sequence to emulate it with the today's git would be:
(1) write-tree (of the WD_Prefix part of the subtree),
(2) read-tree HEAD (to populate the index fully),
(3) piping a massaged output from git-ls-files WD_prefix to
update-index --index-info, followed by read-tree
--prefix=WD_prefix to swap the partial tree in to
WD_prefix,
(4) write-tree (to get the final result).
If you want to do per-path-inside-directory checkout (your 2),
this combining step would need to be even more complex. You can
do that by hand (reading ls-tree and ls-files and driving
update-index --index-info yourself) but it certainly would be
more involved. But it's just a matter of Porcelain programming
;-) [*1*].
But a good news is that today's git core lets you work in a
sparsely checked out repository without any of the above
crap^Wcomplexity, if you drop the WD_Prefix and per
path-inside-directory checkout "expectations". Just staying
within the directory you are working in, and saying "commit ."
when you are tempted to say "commit -a", would be more or less
what are needed.
Note. The "git checkout" Porcelain would want to check-out
everythingd, so a tool to prepare such a sparsely checked out
tree needs to be written if somebody wants to try this, since
the above "good news" is only about "working in" a sparsely
checked out tree.
[*1*] Obviously you would also need to worry about activities
other than making your own changes and committing. When you are
always pulling from a single upstream that never rewinds the
head, the problem becomes simpler, but for other cases (read:
anything that makes distributed version control more interesting
and useful) you would need to worry about merges too. What
happens when the upstream you based your changes on and the
repository you are pulling from today had conflicting changes
outside of your area of interest? Without resolving the
conflicts, you cannot sanely claim you merged the two branches,
and even if you wanted to resolve them yourself, an non-empty
WD_prefix would get in your way.
^ permalink raw reply
* Re: nightly tarballs of git
From: Jakub Narebski @ 2006-09-14 19:48 UTC (permalink / raw)
To: git
In-Reply-To: <20060914193616.GA32735@redhat.com>
Dave Jones wrote:
> I don't recall ever having done anything at all in the dir that
> is being snapshotted. So the only thing that should be happening
> is the side-effects of the script. Here it is in its entirity..
>
> DATE=`date +%Y-%m-%d`
>
> PROJ="git"
> cd ~/git-trees
> if [ -d $PROJ ]; then
> cd $PROJ
Just in case I would add "git checkout master" here.
> git pull -n
> else
> git clone -q git://git.kernel.org/pub/scm/git/git.git
> cd $PROJ
> fi
> snap=git-snapshot-$(date +"%Y%m%d")
> git-tar-tree HEAD $snap | gzip -9 > $PROJ-$DATE.tar.gz
And what is the HEAD? Perhaps you should say 'origin' here instead?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: nightly tarballs of git
From: Dave Jones @ 2006-09-14 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nishanth Aravamudan
In-Reply-To: <7v1wqe45vs.fsf@assigned-by-dhcp.cox.net>
On Thu, Sep 14, 2006 at 12:15:03PM -0700, Junio C Hamano wrote:
> Dave Jones <davej@redhat.com> writes:
> > The original clone of the repo was just a straight clone of git://git.kernel.org/pub/scm/git/git.git
>
> When the build procesure assigns the version to the generated
> git binary, it does these checks and takes the first one:
>
> - Run "git describe" at the top of the source tree. If it
> returns some version (not an error message), use it. This
> case should not apply here since we are talking about a
> tarball of a working tree, and it does not have a repository.
On the server this is running on, the returns v1.3.3-g7f7e6ea
> - See if 'version' file exists at the top of the source tree,
> and uses what is recorded there. This file is placed in the
> resulting tarball by the "make dist" target of the toplevel
> Makefile.
> - Otherwise use DEF_VER hardcoded in GIT-VERSION-GEN script.
> The 1.4.2 series is shipped with DEF_VER set to v1.4.2.GIT,
> so this does not explain why Nashanth sees "1.3.GIT" (or
> "v1.3.GIT", if the original report did not copy it right).
>
> I just snarfed your snapshot tarball from a few days ago, and I
> do not see any version file there (which indicates that it is
> not a product of "make dist"). Interestingly enough DEF_VER is
> set to v1.3.GIT in GIT-VERSION-GEN. This line was changed from
> v1.3.GIT to v1.4.GIT with commit 41292dd on June 10th and then
> updated to v1.4.2.GIT with commit 5a71682 on August 3rd.
>
> So a short conclusion is that the directory you are tarring up
> does not have snapshot of my tree.
>
> I would like to understand why. If an automated 'pull' is
> failing, that is somewhat worrysome, because I presume you do
> not do any development of your own in your snapshot directory
> and in that case everything should fast forward. Even if 'pull'
> failed somehow, if it is not reporting its failure, it is even
> more worrysome.
I don't recall ever having done anything at all in the dir that
is being snapshotted. So the only thing that should be happening
is the side-effects of the script. Here it is in its entirity..
DATE=`date +%Y-%m-%d`
PROJ="git"
cd ~/git-trees
if [ -d $PROJ ]; then
cd $PROJ
git pull -n
else
git clone -q git://git.kernel.org/pub/scm/git/git.git
cd $PROJ
fi
snap=git-snapshot-$(date +"%Y%m%d")
git-tar-tree HEAD $snap | gzip -9 > $PROJ-$DATE.tar.gz
mv $PROJ-$DATE.tar.gz ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/
rm -f ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-`date +%Y-%m-%d --date="7 days ago"`.tar.gz
ln -sf ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-$DATE.tar.gz ~/sites/www.codemonkey.org.uk/htdocs/projects/git-snapshots/$PROJ/$PROJ-latest.tar.gz
#git-fsck-objects --full
I'll save that broken dir away somewhere, and rerun the script
(which as you can see above will make it reclone from scratch).
If you want a copy of the .git of the broken tree I can put that up somewhere too.
Hmm, I just checked the mail cron sent out recently (sadly I don't
have an archive of older mails). It does look a bit strange..
got 49be764e948668341034e121fad5cf07ab079bff
got 415c09ba10a391cec60c939da1722c83df7cd906
* refs/heads/origin: fast forward to branch 'master' of http://www.kernel.org/pub/scm/git/git
from 8a5dbef8ac24bc5a28409d646cf3ff6db0cccb3f to 38529e28a4f465ad5d5f2fa249ca17da680bac5f
Failed to fetch refs/heads/gb/diffdelta from http://www.kernel.org/pub/scm/git/git.git
Interesting. It looks like my original clone was over http.
Another reason to reclone over git: I guess.
Dave
^ permalink raw reply
* [PATCH (take 3)] gitweb: Use File::Find::find in git_get_projects_list
From: Jakub Narebski @ 2006-09-14 19:34 UTC (permalink / raw)
To: git; +Cc: Junio Hamano
In-Reply-To: <200609140839.56181.jnareb@gmail.com>
Earlier code to get list of projects when $projects_list is a
directory (e.g. when it is equal to $projectroot) had a hardcoded flat
(one level) list of directories. Allow for projects to be in
subdirectories also for $projects_list being a directory by using
File::Find.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Use anonymous subroutine to avoid
Variable "@list" will not stay shared at gitweb.perl line 727.
warning. Check for the current directory to avoid substr outside
string warning.
gitweb/gitweb.perl | 30 ++++++++++++++++++++----------
1 files changed, 20 insertions(+), 10 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c3544dd..bea75d3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -715,16 +715,26 @@ sub git_get_projects_list {
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
- opendir my ($dh), $dir or return undef;
- while (my $dir = readdir($dh)) {
- if (-e "$projectroot/$dir/HEAD") {
- my $pr = {
- path => $dir,
- };
- push @list, $pr
- }
- }
- closedir($dh);
+ my $pfxlen = length("$dir");
+
+ File::Find::find({
+ follow_fast => 1, # follow symbolic links
+ dangling_symlinks => 0, # ignore dangling symlinks, silently
+ wanted => sub {
+ # skip current directory
+ return if (m!^/|.|..$!);
+ # only directories can be git repositories
+ return unless (-d $_);
+
+ my $subdir = substr($File::Find::name, $pfxlen + 1);
+ # we check related file in $projectroot
+ if (-e "$projectroot/$subdir/HEAD") {
+ push @list, { path => $subdir };
+ $File::Find::prune = 1;
+ }
+ },
+ }, "$dir");
+
} elsif (-f $projects_list) {
# read from file(url-encoded):
# 'git%2Fgit.git Linus+Torvalds'
--
1.4.2
^ permalink raw reply related
* Re: Notes on supporting Git operations in/on partial Working Directories
From: Shawn Pearce @ 2006-09-14 19:21 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <4509A7EC.9090805@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> wrote:
> The contents of the index file still reflect the full tree but flag each
> object (file or symlink) separately as part of the checkout or not. The
> WD_Prefix string is so that a partial checkout consisting of only
> objects somewhere in the a/b/c/d/ tree can be found in the working
> directory without the a/b/c/d/ prefix to the path of the object.
Why not just load a partial index?
If we only want "a/b/c/d" subtree then only load that into the index.
At git-write-tree time return the new root tree by loading the tree
of the current `HEAD` commit and walking down to a/b/c/d, updating
that with the tree from the index, then walking back updating each
node you recursed down through. Finally output the new root tree.
The advantage is that if you have a subtree checked out you aren't
working with the entire massive index.
But how does this let the user checkout and work on the 10 top
level directories at once and perform an atomic commit to all
of them, but not checkout the other 100+ top level directories?
As I recall this was desired in the Mozilla project for example.
> [*3*] Possibly split the index up by directory and store the parts in
> the working directory. An index "distributed" in this way would have
> a "natural" cache-tree built in and (finally) be able support empty
> directories.
Please, no. On a project with a large number of directories
operations like git-write-tree would take a longer time to scan the
index and generate the new trees. I unfortunately work on such
projects as its common for Java applications to be very deeply
nested and large projects have a *lot* of directories.
--
Shawn.
^ permalink raw reply
* Re: nightly tarballs of git
From: Junio C Hamano @ 2006-09-14 19:15 UTC (permalink / raw)
To: Dave Jones; +Cc: git, Nishanth Aravamudan
In-Reply-To: <20060914175116.GB22279@redhat.com>
Dave Jones <davej@redhat.com> writes:
> On Thu, Sep 14, 2006 at 10:27:54AM -0700, Nishanth Aravamudan wrote:
> > Hi Dave,
> >
> > For simplicities sake when I was running Debian Sarge on a server here,
> > I was using your nightly tarballs of git to build a fresh up-to-date
> > version on a regular basis. I noticed though, that the tarballs result
> > in gits with a version of 1.3.GIT, while the git repository is at
> > 1.4.2.1. Is that expected?
>
> No, it isn't. (at least by me).
> What the snapshotting script does when cron runs it is just a 'git pull'
> on a repo that was cloned a while back when I first set up the snapshotting
> script. I could change it to do a fresh clone each time it runs, but
> that seems somewhat wasteful when most of the time there's nothing new to pull.
>
> gitsters, any ideas what could be going wrong here ?
> The original clone of the repo was just a straight clone of git://git.kernel.org/pub/scm/git/git.git
When the build procesure assigns the version to the generated
git binary, it does these checks and takes the first one:
- Run "git describe" at the top of the source tree. If it
returns some version (not an error message), use it. This
case should not apply here since we are talking about a
tarball of a working tree, and it does not have a repository.
- See if 'version' file exists at the top of the source tree,
and uses what is recorded there. This file is placed in the
resulting tarball by the "make dist" target of the toplevel
Makefile.
- Otherwise use DEF_VER hardcoded in GIT-VERSION-GEN script.
The 1.4.2 series is shipped with DEF_VER set to v1.4.2.GIT,
so this does not explain why Nashanth sees "1.3.GIT" (or
"v1.3.GIT", if the original report did not copy it right).
I just snarfed your snapshot tarball from a few days ago, and I
do not see any version file there (which indicates that it is
not a product of "make dist"). Interestingly enough DEF_VER is
set to v1.3.GIT in GIT-VERSION-GEN. This line was changed from
v1.3.GIT to v1.4.GIT with commit 41292dd on June 10th and then
updated to v1.4.2.GIT with commit 5a71682 on August 3rd.
So a short conclusion is that the directory you are tarring up
does not have snapshot of my tree.
I would like to understand why. If an automated 'pull' is
failing, that is somewhat worrysome, because I presume you do
not do any development of your own in your snapshot directory
and in that case everything should fast forward. Even if 'pull'
failed somehow, if it is not reporting its failure, it is even
more worrysome.
^ permalink raw reply
* Re: [PATCH (amend)] gitweb: Use File::Find::find in git_get_projects_list
From: Jakub Narebski @ 2006-09-14 19:14 UTC (permalink / raw)
To: git
In-Reply-To: <200609141939.39406.jnareb@gmail.com>
Gaah, the code spews quite a lot of warnings as of now.
Variable "$pfxlen" will not stay shared at gitweb.perl line 724.
Variable "@list" will not stay shared at gitweb.perl line 727.
...
--
Jakub Narebski
^ permalink raw reply
* Notes on supporting Git operations in/on partial Working Directories
From: A Large Angry SCM @ 2006-09-14 19:05 UTC (permalink / raw)
To: git
Notes on supporting Git operations in/on partial Working Directories
====================================================================
Motivation
----------
Be able to checkout only part of a tree, do some work, and commit the
changes. Support for partial working directories is also (almost) a
requirement for supporting partial repositories.
Expectations
------------
All Git commands that currently work with the index or the working
directory will work with indexes or working directories that are partial
checkouts.
Leading directories common to all objects of a partial checkout are not
present in the working directory.
The contents of a partial working directory can be determined on an path
by path basis; entire directories are not required.
Implementation Sketch
---------------------
The minimum required changes[*1*][*2*][*3*] to the index file to support
partial checkouts are:
1) the addition of WD_Prefix string to hold the common path prefix of
all objects in the working directory. For a full checkout, the WD_Prefix
string would be empty.
2) A (new) flag for each entry in the index indicating whether or not
the object is in the partial checkout.
The contents of the index file still reflect the full tree but flag each
object (file or symlink) separately as part of the checkout or not. The
WD_Prefix string is so that a partial checkout consisting of only
objects somewhere in the a/b/c/d/ tree can be found in the working
directory without the a/b/c/d/ prefix to the path of the object.
All the Git commands that use the index file will need to be changed to
support this but the transfer protocols do not need to change.
Notes
-----
[*1*] As long as the index file structure is being changed, it may be
worth while also including the ideas in:
http://www.gelato.unsw.edu.au/archives/git/0601/15471.html
http://www.gelato.unsw.edu.au/archives/git/0601/15483.html
http://www.gelato.unsw.edu.au/archives/git/0601/15484.html
Except for the "bind" parts since I still think that is a bad idea.
[*2*] The index "TREE" (cache-tree) extension should also become a
required part of the index.
[*3*] Possibly split the index up by directory and store the parts in
the working directory. An index "distributed" in this way would have
a "natural" cache-tree built in and (finally) be able support empty
directories.
^ permalink raw reply
* Re: [PATCH] gitweb: Use File::Find::find in git_get_projects_list
From: Jakub Narebski @ 2006-09-14 18:43 UTC (permalink / raw)
To: git
In-Reply-To: <7vbqpi47vi.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Side note:
>
> While
>
> return unless -d $_
>
> there is definitely more correct than "return unless -d _" which
> is not, it is not the most efficient. Because you use fast_xxx,
> you know the last stat was lstat so "-d _" would be true if the
> thing you are looking at is a real directory and will be a
> zero-cost operation. The only case you want to be careful is a
> symlink pointing at a directory, so
>
> return unless ((-d _) || (-l _ && -d $_))
>
> would be more efficient.
>
> I have a strange suspicion that Merlyn will soon join us with
> more expertise if we keep talking about Perl ;-)
Truth to be told, I didn't know about '-d _', and File::Find(3pm)
does talk only about $_.
Besides, I guess that the possible speedup is negligible, and of
course depend if for example the whole $projectroot aka. $projects_list
is for example populated by symlinks. Then it would be slower.
This is the place where more readable should win.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Use File::Find::find in git_get_projects_list
From: Junio C Hamano @ 2006-09-14 18:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <7v1wqe6buv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Not true. Link to directory is both -d $_ and -l $_, so
>>
>> return unless (-d $_ || (-l $_ && -d readlink($_)));
>>
>> is not needed.
>
> I think you mis-read what I said. I first wondered why you did
> not say "return unless -d _" and wrote (seemingly more
> inefficient) "return unless -d $_". The comment is to clarify
> why '$' is needed.
>
> In other words, after this setup:
>
> $ rm -fr d dl
> $ mkdir d
> $ ln -s d dl
>
> you do not see an output from this:
>
> $ perl -e 'lstat "dl"; print "is-dir\n" if -d _;'
>
> but you do from this:
>
> $ perl -e 'lstat "dl"; print "is-dir\n" if -d "dl";'
Side note:
While
return unless -d $_
there is definitely more correct than "return unless -d _" which
is not, it is not the most efficient. Because you use fast_xxx,
you know the last stat was lstat so "-d _" would be true if the
thing you are looking at is a real directory and will be a
zero-cost operation. The only case you want to be careful is a
symlink pointing at a directory, so
return unless ((-d _) || (-l _ && -d $_))
would be more efficient.
I have a strange suspicion that Merlyn will soon join us with
more expertise if we keep talking about Perl ;-)
^ permalink raw reply
* Re: [PATCH 2/2] Handle invalid argc gently
From: Dmitry V. Levin @ 2006-09-14 18:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7virjq4cfj.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 743 bytes --]
On Thu, Sep 14, 2006 at 09:53:36AM -0700, Junio C Hamano wrote:
[...]
> >> What is the valid reason to do execlp("git", NULL, NULL)?
> >
> > Personally I do not plan to execute git this way on regular basis, indeed. :)
> >
> > But argc == 0 is allowed, so why should git crash?
>
> Oh, no I was not arguing for making git crash. I was just
> trying to learn if there is a valid reason to choose to, or
> common misconfiguration that causes it to, run with ac == 0,
> since I did not think of any.
Well, the execlp example is somewhat dragged in.
More common case is execvp:
char *argv[] = { NULL };
execvp("git", argv);
The argv array may be empty for various reasons, e.g. pointer arithmetic
mistakes.
--
ldv
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: nightly tarballs of git
From: Dave Jones @ 2006-09-14 17:51 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: git
In-Reply-To: <20060914172754.GF8013@us.ibm.com>
On Thu, Sep 14, 2006 at 10:27:54AM -0700, Nishanth Aravamudan wrote:
> Hi Dave,
>
> For simplicities sake when I was running Debian Sarge on a server here,
> I was using your nightly tarballs of git to build a fresh up-to-date
> version on a regular basis. I noticed though, that the tarballs result
> in gits with a version of 1.3.GIT, while the git repository is at
> 1.4.2.1. Is that expected?
No, it isn't. (at least by me).
What the snapshotting script does when cron runs it is just a 'git pull'
on a repo that was cloned a while back when I first set up the snapshotting
script. I could change it to do a fresh clone each time it runs, but
that seems somewhat wasteful when most of the time there's nothing new to pull.
gitsters, any ideas what could be going wrong here ?
The original clone of the repo was just a straight clone of git://git.kernel.org/pub/scm/git/git.git
Dave
^ permalink raw reply
* Add "-h/-H" parsing to "git grep"
From: Linus Torvalds @ 2006-09-14 17:45 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
It turns out that I actually wanted to avoid the filenames (because I
didn't care - I just wanted to see the context in which something was
used) when doing a grep. But since "git grep" didn't take the "-h"
parameter, I ended up having to do "grep -5 -h *.c" instead.
So here's a trivial patch that adds "-h" (and thus has to enable -H too)
to "git grep" parsing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
I just verified that it does the same thing as GNU grep with some of the
combinations like "-l -h" and "-h -n", but I didn't bother digging any
deeper. Regardless, it doesn't change any behaviour unless people start
using "-h", and when they do, it's at least no worse than the old
behaviour (which was to say "I can't do that, Dave" or something).
diff --git a/builtin-grep.c b/builtin-grep.c
index 6430f6d..ed87a55 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -138,6 +138,7 @@ #define GREP_BINARY_TEXT 2
unsigned binary:2;
unsigned extended:1;
unsigned relative:1;
+ unsigned pathname:1;
int regflags;
unsigned pre_context;
unsigned post_context;
@@ -316,7 +317,8 @@ static int word_char(char ch)
static void show_line(struct grep_opt *opt, const char *bol, const char *eol,
const char *name, unsigned lno, char sign)
{
- printf("%s%c", name, sign);
+ if (opt->pathname)
+ printf("%s%c", name, sign);
if (opt->linenum)
printf("%d%c", lno, sign);
printf("%.*s\n", (int)(eol-bol), bol);
@@ -691,6 +693,8 @@ static int external_grep(struct grep_opt
push_arg("-F");
if (opt->linenum)
push_arg("-n");
+ if (!opt->pathname)
+ push_arg("-h");
if (opt->regflags & REG_EXTENDED)
push_arg("-E");
if (opt->regflags & REG_ICASE)
@@ -911,6 +915,7 @@ int cmd_grep(int argc, const char **argv
memset(&opt, 0, sizeof(opt));
opt.prefix_length = (prefix && *prefix) ? strlen(prefix) : 0;
opt.relative = 1;
+ opt.pathname = 1;
opt.pattern_tail = &opt.pattern_list;
opt.regflags = REG_NEWLINE;
@@ -970,10 +975,12 @@ int cmd_grep(int argc, const char **argv
opt.linenum = 1;
continue;
}
+ if (!strcmp("-h", arg)) {
+ opt.pathname = 0;
+ continue;
+ }
if (!strcmp("-H", arg)) {
- /* We always show the pathname, so this
- * is a noop.
- */
+ opt.pathname = 1;
continue;
}
if (!strcmp("-l", arg) ||
^ permalink raw reply related
* [PATCH (amend)] gitweb: Use File::Find::find in git_get_projects_list
From: Jakub Narebski @ 2006-09-14 17:39 UTC (permalink / raw)
To: git; +Cc: Junio Hamano
In-Reply-To: <200609140839.56181.jnareb@gmail.com>
Earlier code to get list of projects when $projects_list is a
directory (e.g. when it is equal to $projectroot) had a hardcoded flat
(one level) list of directories. Allow for projects to be in
subdirectories also for $projects_list being a directory by using
File::Find.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.perl | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index c3544dd..27641a6 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -715,16 +715,26 @@ sub git_get_projects_list {
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
- opendir my ($dh), $dir or return undef;
- while (my $dir = readdir($dh)) {
- if (-e "$projectroot/$dir/HEAD") {
- my $pr = {
- path => $dir,
- };
- push @list, $pr
+ my $pfxlen = length("$dir");
+
+ sub wanted {
+ # only directories can be git repositories
+ return unless (-d $_);
+
+ my $subdir = substr($File::Find::name, $pfxlen + 1);
+ # we check related file in $projectroot
+ if (-e "$projectroot/$subdir/HEAD") {
+ push @list, { path => $subdir };
+ $File::Find::prune = 1;
}
}
- closedir($dh);
+
+ File::Find::find({
+ follow_fast => 1, # follow symbolic links
+ dangling_symlinks => 0, # ignore dangling symlinks, silently
+ wanted => \&wanted,
+ }, "$dir");
+
} elsif (-f $projects_list) {
# read from file(url-encoded):
# 'git%2Fgit.git Linus+Torvalds'
--
1.4.2
^ permalink raw reply related
* Re: open(2) vs fopen(3)
From: Linus Torvalds @ 2006-09-14 17:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: moreau francis, git
In-Reply-To: <7vr6ye4d64.fsf@assigned-by-dhcp.cox.net>
On Thu, 14 Sep 2006, Junio C Hamano wrote:
>
> Another issue related with this is that stdio implementations
> tend to have unintuitive interaction with signals, one fine
> example of it being the problem we fixed with commit fb7a653,
> where on Solaris fgets(3) did not restart the underlying read(2)
> upon SIGALRM.
Yeah. However, I think it's worth just posting the code in question to
explain _why_ error handling with stdio sucks so badly, and why nobody
does it..
Here's the snippet:
if (!fgets(line, sizeof(line), stdin)) {
if (feof(stdin))
break;
if (!ferror(stdin))
die("fgets returned NULL, not EOF, not error!");
if (errno != EINTR)
die("fgets: %s", strerror(errno));
clearerr(stdin);
so with the <stdio.h> functions, you have to check FOUR DIFFERENT THINGS
(1: return value, 2: feof() value, 3: ferror() value, and 4: errno) to get
things right, and to add insult to injury, you then have to do an explicit
clear.
In other words, the fundamental reason nobody bothers checking errors with
stdio is that stdio just makes it a damn pain in the ass to do so - by
having a million different thing you have to do (and ordering actually
matters).
In contrast, the <unistd.h> interfaces are a paragon of clarity: you check
just two things - the return value, and possibly "errno".
Now, <unistd.h> isn't perfect either, and in the kernel we have simplified
things further, by getting rid of "errno", and just having the return
value contain errno too. Making things not only trivially thread-safe, but
also actually easier to code and understand, because you don't have
anything to be confused about: the return value is always the only thing
you need to look at in order to know what went wrong.
But unistd.h sure is a lot better than stdio in this area. Of course,
stdio.h is just a lot easier to use when you don't actually care about the
errors, which is also partly the _reason_ why caring about errors is so
hard (the whole separate clearerr() and ferror() interfaces exist exactly
_because_ people don't care about errors in many cases, and you're
supposed to maybe have some way to test at the end whether an error
happened or not).
So stdio.h is pretty much geared towards delayed error handling, which in
practice ends up often meaning "no error handling at all".
Linus
^ permalink raw reply
* Re: cvs import
From: Jon Smirl @ 2006-09-14 17:17 UTC (permalink / raw)
To: Michael Haggerty; +Cc: monotone-devel, dev, git, Jakub Narebski
In-Reply-To: <45098AE0.6030409@alum.mit.edu>
On 9/14/06, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Jon Smirl wrote:
> > On 9/14/06, Jakub Narebski <jnareb@gmail.com> wrote:
> >> Shawn Pearce wrote:
> >>
> >> > Originally I wanted Jon Smirl to modify the cvs2svn (...)
> >>
> >> By the way, will cvs2git (modified cvs2svn) and git-fast-import publicly
> >> available?
> >
> > It has some unresolved problems so I wasn't spreading it around everywhere.
> >
> > It is based on cvs2svn from August. There has been too much change to
> > the current cvs2svn to merge it anymore. [...]
> >
> > If the repo is missing branch tags cvs2svn may turn a single missing
> > branch into hundreds of branches. The Mozilla repo has about 1000
> > extra branches because of this.
>
> [To explain to our studio audience:] Currently, if there is an actual
> branch in CVS but no symbol associated with it, cvs2svn generates branch
> labels like "unlabeled-1.2.3", where "1.2.3" is the branch revision
> number in CVS for the particular file. The problem is that the branch
> revision numbers for files in the same logical branch are usually
> different. That is why many extra branches are generated.
>
> Such unnamed branches cannot reasonably be accessed via CVS anyway, and
> somebody probably made the conscious decision to delete the branch from
> CVS (though without doing it correctly). Therefore such revisions are
> probably garbage. It would be easy to add an option to discard such
> revisions, and we should probably do so. (In fact, they can already be
> excluded with "--exclude=unlabeled-.*".) The only caveat is that it is
> possible for other, named branches to sprout from an unnamed branch. In
> this case either the second branch would have to be excluded too, or the
> unlabeled branch would have to be included.
In MozCVS there are important branches where the first label has been
deleted but there are subsequent branches off from the first branch.
These subsequent branches are still visible in CVS. Someone else had
this same problem on the cvs2svn list. This has happen twice on major
branches.
Manually looking at one of these it looks like the author wanted to
change the branch name. They made a branch with the wrong name,
branched again with the new name, and deleted the first branch.
> Alternatively, there was a suggestion to add heuristics to guess which
> files' "unlabeled" branches actually belong in the same original branch.
> This would be a lot of work, and the result would never be very
> accurate (for one thing, there is no evidence of the branch whatsoever
> in files that had no commits on the branch).
You wrote up a detailed solution for this a few weeks ago on the
cvs2svn list. The basic idea is to look at the change sets on the
unlabeled branches. If change sets span multiple unlabeled branches,
there should be one unlabeled branch instead of multiple ones. That
would work to reduce the number of unlabeled branches down from 1000
to the true number which I believe is in the 10-20 range.
Would the dependency based model make these relationships more obvious?
>
> Other ideas are welcome.
>
> Michael
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Enable the packed refs file format
From: Linus Torvalds @ 2006-09-14 17:14 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This actually "turns on" the packed ref file format, now that the
infrastructure to do so sanely exists (ie notably the change to make the
reference reading logic take refnames rather than pathnames to the loose
objects that no longer necessarily even exist).
In particular, when the ref lookup hits a refname that has no loose file
associated with it, it falls back on the packed-ref information. Also, the
ref-locking code, while still using a loose file for the locking itself
(and _creating_ a loose file for the new ref) no longer requires that the
old ref be in such an unpacked state.
Finally, this does a minimal hack to git-checkout.sh to rather than check
the ref-file directly, do a "git-rev-parse" on the "heads/$refname".
That's not really wonderful - we should rather really have a special
routine to verify the names as proper branch head names, but it is a
workable solution for now.
With this, I can literally do something like
git pack-refs
find .git/refs -type f -print0 | xargs -0 rm -f --
and the end result is a largely working repository (ie I've done two
commits - which creates _one_ unpacked ref file - done things like run
"gitk" and "git log" etc, and it all looks ok).
There are probably things missing, but I'm hoping that the missing things
are now of the "small and obvious" kind, and that somebody else might want
to start looking at this too. Hint hint ;)
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This obviously depends on the lt/refs branch in Junio's tree, that is
currently only in -pu.
diff --git a/git-checkout.sh b/git-checkout.sh
index 580a9e8..c60e029 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -22,7 +22,7 @@ while [ "$#" != "0" ]; do
shift
[ -z "$newbranch" ] &&
die "git checkout: -b needs a branch name"
- [ -e "$GIT_DIR/refs/heads/$newbranch" ] &&
+ git-rev-parse --symbolic "heads/$newbranch" >&/dev/null &&
die "git checkout: branch $newbranch already exists"
git-check-ref-format "heads/$newbranch" ||
die "git checkout: we do not like '$newbranch' as a branch name."
@@ -51,7 +51,7 @@ while [ "$#" != "0" ]; do
fi
new="$rev"
new_name="$arg^0"
- if [ -f "$GIT_DIR/refs/heads/$arg" ]; then
+ if git-rev-parse "heads/$arg^0" >&/dev/null; then
branch="$arg"
fi
elif rev=$(git-rev-parse --verify "$arg^{tree}" 2>/dev/null)
diff --git a/refs.c b/refs.c
index 50c25d3..134c0fc 100644
--- a/refs.c
+++ b/refs.c
@@ -28,6 +28,8 @@ static const char *parse_ref_line(char *
if (!isspace(line[40]))
return NULL;
line += 41;
+ if (isspace(*line))
+ return NULL;
if (line[len] != '\n')
return NULL;
line[len] = 0;
@@ -168,6 +170,14 @@ const char *resolve_ref(const char *ref,
* reading.
*/
if (lstat(path, &st) < 0) {
+ struct ref_list *list = get_packed_refs();
+ while (list) {
+ if (!strcmp(ref, list->name)) {
+ hashcpy(sha1, list->sha1);
+ return ref;
+ }
+ list = list->next;
+ }
if (reading || errno != ENOENT)
return NULL;
hashclr(sha1);
@@ -400,22 +410,13 @@ int check_ref_format(const char *ref)
static struct ref_lock *verify_lock(struct ref_lock *lock,
const unsigned char *old_sha1, int mustexist)
{
- char buf[40];
- int nr, fd = open(lock->ref_file, O_RDONLY);
- if (fd < 0 && (mustexist || errno != ENOENT)) {
- error("Can't verify ref %s", lock->ref_file);
- unlock_ref(lock);
- return NULL;
- }
- nr = read(fd, buf, 40);
- close(fd);
- if (nr != 40 || get_sha1_hex(buf, lock->old_sha1) < 0) {
- error("Can't verify ref %s", lock->ref_file);
+ if (!resolve_ref(lock->ref_name, lock->old_sha1, mustexist)) {
+ error("Can't verify ref %s", lock->ref_name);
unlock_ref(lock);
return NULL;
}
if (hashcmp(lock->old_sha1, old_sha1)) {
- error("Ref %s is at %s but expected %s", lock->ref_file,
+ error("Ref %s is at %s but expected %s", lock->ref_name,
sha1_to_hex(lock->old_sha1), sha1_to_hex(old_sha1));
unlock_ref(lock);
return NULL;
@@ -427,6 +428,7 @@ static struct ref_lock *lock_ref_sha1_ba
int plen,
const unsigned char *old_sha1, int mustexist)
{
+ char *ref_file;
const char *orig_ref = ref;
struct ref_lock *lock;
struct stat st;
@@ -445,13 +447,14 @@ static struct ref_lock *lock_ref_sha1_ba
}
lock->lk = xcalloc(1, sizeof(struct lock_file));
- lock->ref_file = xstrdup(git_path("%s", ref));
+ lock->ref_name = xstrdup(ref);
lock->log_file = xstrdup(git_path("logs/%s", ref));
- lock->force_write = lstat(lock->ref_file, &st) && errno == ENOENT;
+ ref_file = git_path(ref);
+ lock->force_write = lstat(ref_file, &st) && errno == ENOENT;
- if (safe_create_leading_directories(lock->ref_file))
- die("unable to create directory for %s", lock->ref_file);
- lock->lock_fd = hold_lock_file_for_update(lock->lk, lock->ref_file, 1);
+ if (safe_create_leading_directories(ref_file))
+ die("unable to create directory for %s", ref_file);
+ lock->lock_fd = hold_lock_file_for_update(lock->lk, ref_file, 1);
return old_sha1 ? verify_lock(lock, old_sha1, mustexist) : lock;
}
@@ -479,7 +482,7 @@ void unlock_ref(struct ref_lock *lock)
if (lock->lk)
rollback_lock_file(lock->lk);
}
- free(lock->ref_file);
+ free(lock->ref_name);
free(lock->log_file);
free(lock);
}
@@ -556,7 +559,7 @@ int write_ref_sha1(struct ref_lock *lock
return -1;
}
if (commit_lock_file(lock->lk)) {
- error("Couldn't set %s", lock->ref_file);
+ error("Couldn't set %s", lock->ref_name);
unlock_ref(lock);
return -1;
}
diff --git a/refs.h b/refs.h
index 553155c..af347e6 100644
--- a/refs.h
+++ b/refs.h
@@ -2,7 +2,7 @@ #ifndef REFS_H
#define REFS_H
struct ref_lock {
- char *ref_file;
+ char *ref_name;
char *log_file;
struct lock_file *lk;
unsigned char old_sha1[20];
^ permalink raw reply related
* Re: [PATCH] gitweb: Use File::Find::find in git_get_projects_list
From: Randal L. Schwartz @ 2006-09-14 17:12 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <eec1tp$9c9$1@sea.gmane.org>
>>>>> "Jakub" == Jakub Narebski <jnareb@gmail.com> writes:
Jakub> First benchmarks showed that no_chdir was some faster. I have rechecked,
Jakub> and they are the same within the margin of error, perhaps without
Jakub> no_chdir is slightly faster. 447 +/- 11 ms vs. 450 +/- 10 ms according
Jakub> to ApacheBench (ab -n 10).
Any benchmarks will certainly depend on the O/S as well. The advantage to
chdir is that the name-to-inode lookups don't need to keep retraversing the
upper directories. And keep in mind that caching will affect the benchmarks
on that.
As for that whole -d thing...
If you use _, you have to keep in mind whether the previous call was a stat()
or an lstat(). Both lstat() (explictly) and -l use lstat(). Everything else
is a stat(). So, "-l and not -d" uses an lstat to determine that we're
looking at a symlink, but a stat to determine that the item pointed at is not
a directory. NEVER use readlink(), as it very likely will require a lot of
flattening for you to simulate what the OS does. (See my article on that at
<http://www.stonehenge.com/merlyn/UnixReview/col27.html>.)
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: cvs import
From: Jakub Narebski @ 2006-09-14 17:08 UTC (permalink / raw)
To: monotone-devel; +Cc: dev, git
In-Reply-To: <45098AE0.6030409@alum.mit.edu>
Michael Haggerty wrote:
> Alternatively, there was a suggestion to add heuristics to guess which
> files' "unlabeled" branches actually belong in the same original branch.
> This would be a lot of work, and the result would never be very
> accurate (for one thing, there is no evidence of the branch whatsoever
> in files that had no commits on the branch).
>
> Other ideas are welcome.
Interpolate the state of repository according to timestamps, with some
coarse-grainess of course.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: Use File::Find::find in git_get_projects_list
From: Jakub Narebski @ 2006-09-14 17:02 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz924cxy.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Sorry, this comment was leftover from before, when no_chdir was not
>> used. Then $_ was the last part of directory,...
>
> Ah, thanks. I missed that difference. Did you choose to use
> no_chdir for performance reasons or coding convenience (somehow
> I had an impression that no_chdir would be slower)?
First benchmarks showed that no_chdir was some faster. I have rechecked,
and they are the same within the margin of error, perhaps without
no_chdir is slightly faster. 447 +/- 11 ms vs. 450 +/- 10 ms according
to ApacheBench (ab -n 10).
So it is really the matter of convenience. The default (without no_chdir) is
I think more convenient.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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