Dnia czwartek 14. września 2006 11:40, napisałeś:
> Jakub Narebski <jnareb@xxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html