Sylvain Rabot [off-list ref] writes:
quoted
Wouldn't it be a good idea to somehow make this work well together with
the --user-path feature of git-daemon?
Perhaps the recommended name given in the example shouldn't be ~/gitweb,
but more like ~/public_git, as this is like ~/public_html but for git
repositories. Then the end users will browse
As I said, it's configuration :)
Wrong answer.
Exactly because it is configurable, the document that outlines the
recommended practice should suggest the best convention. My point was
that it is likely to be tied to "git"-ness of the specified directory
under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
name tied to "gitweb"-ness in this document.
On Tue, Nov 17, 2009 at 23:10, Junio C Hamano [off-list ref] wrote:
Sylvain Rabot [off-list ref] writes:
quoted
quoted
Wouldn't it be a good idea to somehow make this work well together with
the --user-path feature of git-daemon?
Perhaps the recommended name given in the example shouldn't be ~/gitweb,
but more like ~/public_git, as this is like ~/public_html but for git
repositories. Then the end users will browse
As I said, it's configuration :)
Wrong answer.
Am I passing a test ?
Exactly because it is configurable, the document that outlines the
recommended practice should suggest the best convention. My point was
that it is likely to be tied to "git"-ness of the specified directory
under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
name tied to "gitweb"-ness in this document.
Again, git is a brand new world for me and I don't know any of his
conventions yet.
I am not trying to impose my own conventions, I am just proposing an idea.
If you like it and want to make it more "git world compliant", please do so.
Junio C Hamano wrote:
Sylvain Rabot [off-list ref] writes:
quoted
quoted
Wouldn't it be a good idea to somehow make this work well together with
the --user-path feature of git-daemon?
Perhaps the recommended name given in the example shouldn't be ~/gitweb,
but more like ~/public_git, as this is like ~/public_html but for git
repositories. Then the end users will browse
As I said, it's configuration :)
Wrong answer.
Exactly because it is configurable, the document that outlines the
recommended practice should suggest the best convention. My point was
that it is likely to be tied to "git"-ness of the specified directory
under $HOME/, not limited to "gitweb"-ness, and it is wrong to recommend a
name tied to "gitweb"-ness in this document.
For starters I think overriding the /~<user> (specifically the ~ here)
is going to be a bad idea no matter what you do and gives the wrong
impression about what / how the request is being responded to. You
might want to try and pick a different delimiter or re-work the rule so
that you could have something like:
http://git.kernel.org/<gitweb urls>
http://git.kernel.org/user/<gitweb urls>
Your also, likely, going to need to take into account things like
index.cgi and gitweb.cgi in the url as things like:
http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=summary
http://git.kernel.org/gitweb.cgi?p=bluetooth/bluez-gnome.git;a=summary
are likely to be correct for almost all installations.
I would agree with Junio on this, if your suggesting a possible practice
you should focus on the best convention. Making it depend on something
like ~/gitweb doesn't make it clear or obvious enough to a user, or an
administrator, that the directory is being exported for the world to
see. There is a reason it's called ~/public_html.
Keep in mind most people are going to read the documentation and
copy/paste what they need and not change anything.
- John 'Warthog9' Hawley
For starters I think overriding the /~<user> (specifically the ~ here) is
going to be a bad idea no matter what you do and gives the wrong impression
about what / how the request is being responded to. You might want to try
and pick a different delimiter or re-work the rule so that you could have
something like:
http://git.kernel.org/<gitweb urls>
http://git.kernel.org/user/<gitweb urls>
Your also, likely, going to need to take into account things like index.cgi
and gitweb.cgi in the url as things like:
http://git.kernel.org/?p=bluetooth/bluez-gnome.git;a=summary
http://git.kernel.org/gitweb.cgi?p=bluetooth/bluez-gnome.git;a=summary
<VirtualHost git.abstraction.fr:80>
ServerAdmin webmaster@abstraction.fr
ServerName git.abstraction.fr:80
DocumentRoot /var/www/sylvain/git.abstraction.fr/html
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel debug
CustomLog /var/www/sylvain/git.abstraction.fr/log/access.log combined
ErrorLog /var/www/sylvain/git.abstraction.fr/log/error.log
ServerSignature On
RewriteEngine on
RewriteLog /var/www/sylvain/git.abstraction.fr/log/rewrite.log
RewriteLogLevel 3
RewriteRule ^/$
/cgi-bin/gitweb.cgi [QSA,L,PT]
RewriteRule ^/gitweb.cgi$
/cgi-bin/gitweb.cgi [QSA,L,PT]
RewriteRule ^/\~([^\/]+)/?$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
RewriteRule ^/\~([^\/]+)/gitweb.cgi$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
RewriteRule ^/users/([^\/]+)/?$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
RewriteRule ^/users/([^\/]+)/gitweb.cgi$
/cgi-bin/gitweb.cgi
[QSA,E=GITWEB_PROJECTROOT:/home/$1/public_git/,L,PT]
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin/">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
Alias /gitweb /usr/share/gitweb/
<Directory "/usr/share/gitweb/">
AllowOverride None
Options +MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
</VirtualHost>
You can test here :
http://git.abstraction.fr/
http://git.abstraction.fr/gitweb.cgi
http://git.abstraction.fr/~sylvain/
http://git.abstraction.fr/~sylvain/gitweb.cgi
http://git.abstraction.fr/users/sylvain/
http://git.abstraction.fr/users/sylvain/gitweb.cgi
The dns record is fresh. If your dns is not up to date the ip is 88.191.254.60.