Jakub Narebski <jnareb@gmail.com> writes:

quoted text
> On Fri, 11 Dec 2009, J.H. wrote:
>
>>>> This is also a not-so-subtle start of trying to break up gitweb into
>>>> separate files for easier maintainability, having everything in a
>>>> single file is just a mess and makes the whole thing more complicated
>>>> than it needs to be.  This is a bit of a baby step towards breaking it
>>>> up for easier maintenance.
>>> 
>>> The question is if easier maintenance and development by spliting
>>> gitweb for developers offsets ease of install for users.
>> 
>> This would just get dropped into the same location that gitweb.cgi 
>> exists in, there is no real difference in installation, and thus I can't 
>> see this as an issue for users.
>
> To be more exact you have to know that you have to drop _generated files_,
> which means (for this version of patch) gitweb.cgi and gitweb_defaults.pl
> (or whatever the generated file with config variables would be named).
>
>
> ATTENTION!

You didn't have to shout.

Any progress on this front?

Not that I am anxious to queue new topics to 'next' right now (we are
frozen for 1.6.6), but I think having what is proven to work well at a
real site like k.org is much better than waiting for an unproven
reimplementation using somebody else's framework only for your theoretical
cleanliness.  John has better things to do than doing such a rewrite
himself, and even if you helped the process by producing a competing
caching scheme based on existing web caching engines, the aggregated
result (not just the web caching engine you base your work on) needs to
get a similar field exposure to prove itself that it can scale to the load
k.org sees, which would be quite a lot of work, no?

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