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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

> 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.

>> > +		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.

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]