Re: [RFCv3 1/2] gitweb: add patch view

> Jakub Narebski <jnareb@gmail.com> writes:
>
>>> +    # The maximum number of patches in a patchset generated in patch
>>> +    # view. Set this to 0 or undef to disable patch view, or to a
>>> +    # negative number to remove any limit.
>>> +    'patches' => {
>>> +            'override' => 1,
>>> +            'default' => [16]},
>>>  );
>>
>> You need to set "'sub' => \&feature_patches" for feature to be
>> override-able at all.  Also features are usually not overridable
>> by default, which reduces load a tiny bit (by _possibly_ not reading
>> config, although that shouldn't matter much now with reading whole
>> commit using single call to git-config, and not one call per variable).
>> And I think the default might be set larger: 'log' view generates
>> as big if not bigger load, and it is split into 100 commits long
>> pages.
>
> I do not think defaulting to 'no' for overridability nor defaulting a new
> feature to 'disabled' have much to do with the load, but they are more
> about the principle of least surprise.  Somebody who runs gitweb in the
> playpen he was given on the server shouldn't be getting a phone call from
> his users late at night complaining that the page his gitweb serves look
> different and has one extra link per each line, only because the sysadmin
> of the server decided to update git to 1.6.1 without telling him.
>
> Once a new version capable of serving a new feature is introduced, he can
> plan, announce and deploy by switching the feature on in his gitweb
> configuration file.
>
> Some things, like sitewide default css changes, cannot be made disabled
> by default.  But a new feature can easily be kept disabled by default not
> to cause needless surprises.