On Tue, Dec 3, 2013 at 11:53 AM, Krzesimir Nowak <krzesimir@xxxxxxxxxxxx> wrote:
> On Mon, 2013-12-02 at 18:34 +0100, Jakub Narębski wrote:
>> W dniu 2013-12-02 13:06, Krzesimir Nowak pisze:
>>> On Mon, 2013-12-02 at 01:21 +0100, Jakub Narębski wrote:
>>>> On Thu, Nov 28, 2013 at 12:44 PM, Krzesimir Nowak
>>>> <krzesimir@xxxxxxxxxxxx> wrote:
>>>>
>>>>> Allow @additional_branch_refs configuration variable to tell gitweb to
>>>>> show refs from additional hierarchies in addition to branches in the
>>>>> list-of-branches view.
>>>>>
>>>>> Signed-off-by: Krzesimir Nowak<krzesimir@xxxxxxxxxxxx>
>>>>
>>>> Why not use %feature hash instead of adding new configuration variable?
>>>> I think that this option is similar enough to 'remote_heads' feature
>>>> (which BTW should be 'remote-heads'), and could conceivably enabled
>>>> on a per-repository basis, i.e. with repository configuration override,
>>>> isn't it?
>>>
>>> I'd like to see some consensus on it before I start changing the patch
>>> again.
>>
>> %feature hash is mainly (but not only) about options that can be
>> configured on per-repository basis. Configuration variables are
>> about options that are per-instance (per gitweb).
>
> Well, I am mostly interested in per-instance configuration in this case,
> but if that is also possible with %feature hash, then ok, I'll try to
> make it work.
Yes, it is possible to have per-instance configuration (you can even
forbid per-repository configuration).
> From what I've seen (correct me please if I got it wrong) feature
> settings is taken from per-repository config file from [gitweb] section.
> If there's nothing then some default value is taken. That default value
> can be overriden with per-instance perl config file.
%feature settings are taken from gitweb configuration (the 'default'
key), and if given feature is overrideable and per-repository configuration
in the form of appropriate key in [gitweb] section of repository config
file exists, it is used instead.
> So it is easy to override it from per-instance perl config by typing:
> $feature{'additional-branch-refs'}{'default'} = ['wip', 'no|tf"un,ny'];
> $feature{'additional-branch-refs'}{'override'} = 1;
Yes. The 'override' is about checking (which imposes a bit of
performance penalty) and respecting per-repository configuration.
> (Note the edge case of refs/no|tf"un,ny, which passes the git
> check-ref-format scrutiny.)
>
> But for now, most of features are quite simple - either booleans,
> integers or list of simple strings (in snapshot feature). What I need
> here is a list of strings, like CSV in following example:
> [gitweb]
> additional_branch_refs = wip,"no|tf""un,ny"
>
> Is dependency on external module like Text::CSV or Text::CSV_XS ok? If
> not, I can hack some CSV reading code.
Why not use space, which is forbidden in refnames, to separate
entries? Similar to feature_snapshot(), which is about comma separated
list, without escaping.
--
Jakub Narebski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html