Re: [PATCH] Git homepage: remove all the references to Cogito

Petr Baudis [off-list ref] writes:

I'm not sure this is good idea, Cogito is still quite frequently used
and it should be documented that it exists.

I think reformulating the mention to cogito (use past sentence like
"cogito was a popular ...") would be better. As a side-effect, it
would also credit you for your work, which I think is fair :-).

-- 
Matthieu

On 10/16/07, Matthieu Moy [off-list ref] wrote:

Petr Baudis [off-list ref] writes:

quoted

I'm not sure this is good idea, Cogito is still quite frequently used
and it should be documented that it exists.

I think reformulating the mention to cogito (use past sentence like
"cogito was a popular ...") would be better. As a side-effect, it
would also credit you for your work, which I think is fair :-).

Yes, I probably be too rude. Sorry abot that Pasky, I just feel like
the home page is a bit confusing with regards to Cogito. My
understanding is that it is no longer maintained and therefore we
probably should not encourage new user to use it.

Maybe changing:
Cogito
    Cogito is a popular version control system on top of Git. It aims
at seamless user interface and ease of use, providing generally
smoother user experience than the "raw" Git interface and indeed also
many other version control systems. However, it also lacks many
advanced capabilities of Git and is currently being slowly phased out.

into
Cogito
    Cogito was a popular version control system on top of Git. It aims
at seamless user interface and ease of use, providing generally
smoother user experience than the "raw" Git interface and indeed also
many other version control systems. However, it also lacks many
advanced capabilities of Git and is not actively maintained any
longer.

Ciao,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/

Hi, I've been using git for a month now and loving it. This is my  
first ever patch for git using git. I spent sometime to find out why  
the project listing is taking 200s, everytime! I guess that gitweb is  
mostly used to serve bare repositories, which would never encounter  
such problems. It takes .2s, after the patch on my laptop. That's  
1000x improvement for me (on Mac OS X 1.4.10.)

__Luke

Signed-off-by: Luke Lu <redacted>
---
gitweb/gitweb.perl |    4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 3064298..a30eef9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl

@@ -1509,16 +1509,20 @@ sub git_get_projects_list {

		# remove the trailing "/"
		$dir =~ s!/+$!!;
		my $pfxlen = length("$dir");
+		my $pfxdepth = ($dir =~ tr!/!!);
		File::Find::find({
			follow_fast => 1, # follow symbolic links
			follow_skip => 2, # ignore duplicates
+			no_chdir => 1, # don't chdir into every directory
			dangling_symlinks => 0, # ignore dangling symlinks, silently
			wanted => sub {
				# skip project-list toplevel, if we get it.
				return if (m!^[/.]$!);
				# only directories can be git repositories
				return unless (-d $_);
+				# don't traverse too deep (Find is super slow on os x)
+				return if tr!/!! - $pfxdepth > 2 && ($File::Find::prune = 1);
				my $subdir = substr($File::Find::name, $pfxlen + 1);
				# we check related file in $projectroot
--
1.5.3.4

Luke Lu wrote:

Hi, I've been using git for a month now and loving it.

Hello Luke, and welcome to the community :)

This is my first ever patch for git using git.

It shows. The patch is whitespace damaged, and the commit message leaves
a little something to desire. I suggest you read through
Documentation/SubmittingPatches and then re-send your patch. Try sending
to yourself and looking at the result with a monospace font. It's what I
always do to make sure patches look okay before sending them to the list.

Not trying to be rude or anything. Oldtime list-members sometimes get to
hear the exact same thing.

Also, Junio, the maintainer, is currently away, so don't worry if your
patches are left in limbo for some time. Someone will pick it up and
carry it forward for Junio to pull, or he'll hack up some script to
get all patces from his mailbox and review them one by one. He's a very
thorough fellow, usually.

I spent sometime to find out why the 
project listing is taking 200s, everytime! I guess that gitweb is mostly 
used to serve bare repositories, which would never encounter such 
problems. It takes .2s, after the patch on my laptop. That's 1000x 
improvement for me (on Mac OS X 1.4.10.)

Sweet job :)

I'll have to test this, as we've got a few repos at work with a checked out
working tree connected to the repos. I haven't run into your issues though,
but perhaps that's because we run it under Linux.

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

  Hi,

On Tue, Oct 16, 2007 at 02:04:14AM -0700, Luke Lu wrote:

Hi, I've been using git for a month now and loving it. This is my first 
ever patch for git using git. I spent sometime to find out why the project 
listing is taking 200s, everytime! I guess that gitweb is mostly used to 
serve bare repositories, which would never encounter such problems. It 
takes .2s, after the patch on my laptop. That's 1000x improvement for me 
(on Mac OS X 1.4.10.)

  that'd be sweet to have but this is unfortunately not so simple; this
change would e.g. break gitweb on repo.or.cz, where some projects can
live quite deep inside the tree due to forks.

  I guess the best way would be to introduce a configuration option that
lets you potentially limit the $pfxdepth, but does not force the limit.

-- 
				Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
                -- James Thurber