On Tue, Dec 10, 2013 at 7:54 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Jakub Narębski <jna...@gmail.com> writes:
>> With multi-valued we won't be able to override earlier / more generic
>> settings... well, unless we add support for no-value, or empty-value
>> as clearer, i.e.
>> extrabranchrefs = sandbox
>> # or extrabranchrefs =
>> extrabranchrefs = wip other
>> resulting in ('wip', 'other').
> Please don't, unless you are going to change the entire config
> machinery (including config.c bits that are used by the rest of the
> system) to follow such a convention to "clear settings so far read".
Right. Also I haven't noticed that gitweb already uses some
multi-valued config variables, though not for %features.
Please disregard this.
>>> +It is an error to specify a ref that does not pass "git check-ref-format"
>>> +scrutiny. Duplicated values are filtered.
>> Hmmm... 'snapshot' feature ignores invalid values, but in this case
>> formerly valid compression schemes might get invalid via tightening
>> %known_snapshot_formats, and we don't want existing config getting
>> suddenly invalid.
> Sorry, but what does check-ref-format have to do with "formerly
> valid compression scheme that suddenly gets invalidated"???
What I started to write was that 'snapshot' feature ignores invalid
values, but halfway through writing it out I have noticed that the
situation is really different.
In 'snapshot' case one can have formerly valid per-repository config,
made invalid by gitweb admin tightening %known_snapshot_formats
(for example removing some compression format due to bug). We
do not want for repository to stop being displayed because of something
that is outside control of repository owner.
In 'check-ref-format' feature we have ref either valid or not. This does
not depend on external factors. Something that is valid ref would
remain valid ref.
So 'snaphot' being forgiving doesn't mean that 'check-ref-format'
should be forgiving.
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