From: Jakub Narebski <jnareb@gmail.com>
To: Bruno Cesar Ribas <ribas@c3sl.ufpr.br>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Added sub get_owner_file which checks if there's a file with project owner name
Date: Tue, 29 Jan 2008 16:28:19 +0100 [thread overview]
Message-ID: <200801291628.21026.jnareb@gmail.com> (raw)
In-Reply-To: <20080129142550.GA25312@c3sl.ufpr.br>
On Tue, 29 Jan 2008, Bruno Cesar Ribas wrote:
> On Tue, Jan 29, 2008 at 03:26:31AM -0800, Jakub Narebski wrote:
>> Bruno Ribas <ribas@c3sl.ufpr.br> writes:
>>
>>> This file ($projectroot/$project/owner) is good to have when we don't want to
>>> maintain a project list AND when we share same SSH account for all projects,
>>> using ssh_acl for example.
>>>
>>> Signed-off-by: Bruno Ribas <ribas@c3sl.ufpr.br>
>>
>> This explanation is a bit too complicated; it explains farther
>> reasons, instead of immediate ones: you don't want to maintain project
>> list file, and all repository directories have to have the same owner
>> (for example when the same SSH account is shared for all projects,
>> using ssh_acl to control access instead).
>
> I'm sorry about this complicated explanation.
It is not [that] bad description, but it could be better. Also, 80 columns
word wrap is good, but 72-76 would be even better :-)
>> Besides with new faster config reader we probably would want to allow
>> to use config file to set owner, instead of adding yet another file to
>> the repo area; see commit 0e121a2cd42d28bc4034feedf8a13c5a91f85bd3
>> "gitweb: Use config file for repository description and URLs"
>> This would have the advantage that you could use system config
>> (/etc/gitconfig) to set fallback owner instead of relying on
>> filesystem. I'm not sure what should be the preference, though:
>> gitweb.owner, then $GIT_DIR/owner, or vice versa? I guess that
>> reading $GIT_DIR/owner should take preference, as it is needed also
>> for projects list page, where ordinary we didn't read individual
>> repositories configuration.
>
> Reading $GIT_DIR/owner would be the preference, Maybe it can generate project
> list page faster when machine have high IO waits (WA).
Yes, I also think so. Two file reads (description + owner) should be
still faster than one running git-config, and parsing its output.
But I think if IO matters it is better to generate projects list; you
can even use gitweb for that, or you can simply add a line with URL
escaped project name (project path) relative to $projectroot, separated
by space from the URL escaped (URI-encoded) project owner. See also
"Gitweb repositories" section in gitweb/INSTALL. Adding projects is
rare event.
> Having gitweb.owner is good too, but as you said I don't need to read
> individual repositories configuration.
>
> Having another file at the repo area is not a problem (my say). Sometimes
> having files appears to be more organized than having everything in one file
> (my say again).
By the way, I have forgot to ask you to add description of new 'owner'
file to "Per-repository gitweb configuration" section in gitweb/README
> I even made another patch about cloneURL, instead of looking for inside files
> and stuff, i made gitweb.conf a variable that says:
> - If i have a prefix path for HTTP,SSH,GIT[protocol]
> Then if this variable is set gitweb only mounts... like
> HTTPPREFIX="http://git.c3sl.ufpr.br/pub/scm"
> and gitweb sets it to $HTTPREFIX/$project
>
> I made this because I don't want to set each project it's clone URL, so this
> makes thing easier! What do you think?
I hope that this hack predates latest improvements to gitweb/README,
as you have just reimplemented GITWEB_BASE_URL build configuration
variable (only single base URL), and @git_base_url_list, which you
can set in gitweb config file (by default gitweb_config.perl).
If you have read current code carefully, you should notice that
currently gitweb generates URLs for repository in the following way:
1. Per repository configuration:
a. $projectroot/$project/cloneurl (one line perl URL)
b. multivalued gitweb.url configuration variable in project config
2. Global gitweb configuration
a. $prefix/$project for each $prefix element in @git_base_url_list,
which is set in gitweb_config.perl
3. Build time defaults
a. Single value in @git_base_url_list set using GITWEB_BASE_URL
build configuration variable
4. Otherwise it is not set (it is empty).
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2008-01-29 15:29 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 3:36 [PATCH] Added sub get_owner_file which checks if there's a file with project owner name Bruno Ribas
2008-01-29 11:26 ` Jakub Narebski
2008-01-29 14:25 ` Bruno Cesar Ribas
2008-01-29 15:28 ` Jakub Narebski [this message]
2008-01-29 17:22 ` Bruno Cesar Ribas
2008-01-29 18:27 ` Jakub Narebski
2008-01-29 20:53 ` Nagy Balázs
2008-01-29 21:36 ` Jakub Narebski
2008-01-30 15:59 ` Nagy Balázs
2008-02-01 13:18 ` Jakub Narebski
2008-02-01 16:11 ` Nagy Balázs
2008-02-01 19:10 ` Robin Rosenberg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200801291628.21026.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=ribas@c3sl.ufpr.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).