Re: [PATCH] gitweb: Add option to limit repositories to be shown by ServerName

2012-08-14 Thread J.H.
On 08/14/2012 10:04 AM, Junio C Hamano wrote:
> Michal Novotny  writes:
> 
>> this is the patch to limit repositories to be shown by the
>> ServerName in the gitweb.cgi script. This is useful for cases
>> you're hosting multiple websites on a single machine and you don't
>> want all the repos to be shown in all of them.
>> ...
>> Use case scenario: Imagine you have one server running HTTPd
>>for 3 domains, let's call them domain1,
>>domain2 and domain3, and you want all of
>>them to have a git server accessible via
>>gitweb at these URLs:
>>1) http://domain1/git
>>2) http://domain2/git
>>3) http://domain3/git
> 
> 
> I do not run gitweb myself, but isn't the problem you are describing
> merely a symptom caused by your  sections that are
> not configured correctly, and instead having a single instance of
> gitweb cgi enabled for all the virtual hosts?  Why does such a
> physical host want to have git repositories for different domains in
> a single place that is covered by a single instance of gitweb (hence
> a single $projectroot) in the first place?  After all, domain1's
> notion of "kernel git repository" http://domain1/git/kernel.git
> might be totally different from that of domain2's, so wouldn't it be
> far more natural to have one $projectroot (hence one instance of
> gitweb) per such domains, configured in their own 
> sections?
> 
> Also, there may even be http://domain3/git that does not want to be
> served by gitweb but something else, e.g. cgit, on the same physical
> host, and in such a case, the approach taken by this patch still uses
> gitweb only to fail the request without letting cgit have its
> chance, no?

The use case scenario is doable with Apache's vhost directives, and is
likely a much better way to accomplish this then trying to teach gitweb
about vhosting.

http://httpd.apache.org/docs/2.2/vhosts/mass.html

should give some hints on how this can be done, but the long and the
short is, single install of gitweb with the config file using, say %0,
to dynamically figure out which domain to work from.

- John


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] gitweb: Add option to limit repositories to be shown by ServerName

2012-08-14 Thread Junio C Hamano
Michal Novotny  writes:

> this is the patch to limit repositories to be shown by the
> ServerName in the gitweb.cgi script. This is useful for cases
> you're hosting multiple websites on a single machine and you don't
> want all the repos to be shown in all of them.
> ...
> Use case scenario: Imagine you have one server running HTTPd
>for 3 domains, let's call them domain1,
>domain2 and domain3, and you want all of
>them to have a git server accessible via
>gitweb at these URLs:
>1) http://domain1/git
>2) http://domain2/git
>3) http://domain3/git


I do not run gitweb myself, but isn't the problem you are describing
merely a symptom caused by your  sections that are
not configured correctly, and instead having a single instance of
gitweb cgi enabled for all the virtual hosts?  Why does such a
physical host want to have git repositories for different domains in
a single place that is covered by a single instance of gitweb (hence
a single $projectroot) in the first place?  After all, domain1's
notion of "kernel git repository" http://domain1/git/kernel.git
might be totally different from that of domain2's, so wouldn't it be
far more natural to have one $projectroot (hence one instance of
gitweb) per such domains, configured in their own 
sections?

Also, there may even be http://domain3/git that does not want to be
served by gitweb but something else, e.g. cgit, on the same physical
host, and in such a case, the approach taken by this patch still uses
gitweb only to fail the request without letting cgit have its
chance, no?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html