On Wed, Dec 3, 2008 at 14:14, Giuseppe Bilotta wrote: > On Wed, Dec 3, 2008 at 2:00 PM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> On Wed, 3 Dec 2008, Giuseppe Bilotta wrote: >>> On Wed, Dec 3, 2008 at 12:19 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >>>> >>>> Perhaps this configuration should also be a feature defined in %feature, >>>> overridable by each repository? If you default it to "disabled" (as any >>>> new feature typically does), you do not have to yank a random number such >>>> as 100 out of thin air. >>> >>> I thought about it, but then I thought it was way too useful for >>> single patches to disable the feature a priori. I'd rather make the >>> default limit much smaller (like the original 16 commits I had in >>> mind, or even less). >> >> Perhaps %feature can be used to configure _maximum_ number of patches >> in 'patch' / 'format_patch' view (gitweb_get_feature... well, sort of >> as gitweb_check_feature would work too), rather than checking if it >> is enabled or disabled? > > The way it's implemented in v2, you just need to set $patch_max in > your local or system config file (e.g. /etc/gitweb.conf). I'm not sure > about the benefit we would gain in going through %feature. Ah, I haven't read patch in detail yet. The (doubtful or not) benefit of going through %feature would be ability to set limits (with perhaps -1 / <0 / undef / '' meaning: unlimited) on per repository basis, with no limit for small repository, some limit for the rest, and no 'patch' view or heavily limited for repository with large size commits. Just my 2 cents. -- Jakub Narebski Poland -- 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
