Re: [PATCH] gitweb: Use File::Find::find in git_get_projects_list

[Jakub Narebski <jnareb@gmail.com>]

Dnia czwartek 14. września 2006 11:40, napisałeś:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
> > ... But I have realized that for gitweb
> > for only one project one could have ".git" as a project name,
> > e.g. by putting $projectroot to be live git repository (working
> > directory of git repository).
> 
> I do not understand this comment.  I have /git/{git,linux-2.6}
> and run test gitweb with projectroot set to /git to see it can
> display them both.  Both are with working tree, so there are
> /git/git/.git and /git/linux-2.6/.git directories.
> 
> Do you mean to say "project name" is always taken from the last
> component of the directory name and the above setup would result
> in ambiguity?  If that is the case that sounds awful, but I
> haven't noticed it.

Sorry, this comment was leftover from before, when no_chdir was not 
used. Then $_ was the last part of directory, and 'return if (/^\./);'
would not take into consideration git/.git nor linux-2.6/.git as
valid project names ($projectroot / $projects_list is stripped from
project name).

Now the test should read "if (m!^.*/\.!)" if we want to skip
dot files and dot directories.

> > It was intended I think to avoid adding '.' and '..' as git 
> > repositories, not stray directories. Well, perhaps index file
> > if it was used.
> 
> Having and not having index are both valid, so there is no value
> in checking the index, even if we wanted to be more paranoid.
> Existence of HEAD, refs/heads, and/or objects/ would be a more
> meaningful alternative, but again only if we wanted to be more
> paranoid.

Sorry for the confusion. By index I meant alternate way of specyfying 
projects, and up till now the only way to specify hierarchical 
repository structure, namely $projects_list being file with encoded
directories and encoded owners (it was named index.aux or 
index/index.aux by default).

> >> > +		File::Find::find({
> >> > +			no_chdir => 1, # do not change directory
> >> > +			follow_fast => 1, # follow symbolic links
> >> 
> >> What is the reason behind choosing follow_fast?  By saying
> >> follow_anything, you choose to care about cases where there are
> >> symlinks under projectroot to point at various projects.  If
> >> that is the case, don't you want to make sure you include the
> >> same project only once?
> >
> > First, it is faster. Second, for testing if it works I used copy
> > of a one "live" git repository I have (git.git repository), by
> > making second symlink to it.
> 
> That was not what I wanted to ask; slower and correct is always
> preferred over fast and incorrect.  I did not see anything that
> compensates the duplicates follow_fast might give you in the
> code, so I wondered there were some other trick you used to avoid
> it.
> 
> In other words, "because I have such and such check to avoid
> duplicates, so I can safely use 'follow_fast', without using
> slower 'follow'" was the answer I was after.

First of all, why duplicated repositories are considered error?
It is perhaps error/mistake (besides testing of course) in doing the 
layout of repositories (projectroot), but it is not that something bad 
would happen if there are duplicated repositories.

Second, follow_fast is faster, especially that in gitweb we would 
have to set "follow_skip => 2" to not spew errors to web server log when 
there are duplicated repositories. 

-- 
Jakub Narebski
Poland