From: Jakub Narebski <jnareb@gmail.com>
To: "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>
Cc: "Junio C Hamano" <gitster@pobox.com>,
git@vger.kernel.org, "Petr Baudis" <pasky@suse.cz>
Subject: Re: [RFCv3 1/2] gitweb: add patch view
Date: Thu, 4 Dec 2008 02:48:59 +0100 [thread overview]
Message-ID: <200812040249.01374.jnareb@gmail.com> (raw)
In-Reply-To: <cb7bb73a0812031620s2459f773q3db33971e3507b2f@mail.gmail.com>
On Thu, Dec 4, 2008 at 01:20, Giuseppe Bilotta wrote:
> On Thu, Dec 4, 2008 at 12:55 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Giuseppe Bilotta <giuseppe.bilotta@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]},
Errr... you need something like 'sub' => \&feature_patches for override
to actually work, I think.
>>> );
>>
>> Looking at the existing entries in the %feature hash, it seems that it is
>> our tradition that a new feature starts as disabled and not overridable
>> (see 'ctags' in the context above).
>
> I always assumed that the disabled default was related to how invasive
> the changes would be (to the UI or computationally-wise). As for the
> overridability, that's actually the only reason why it would make
> sense to put in the %feature hash ... otherwise a conf-settable
> $patch_max (as in v2) would have been enough.
Add to that the fact that this patch just adds the new view, like for
example in the case of 'snapshot' link, which was turned on... but fact,
it was by default not overridable. I would agree that it can be turned
on with low limit but not overridable in introductory patch.
>>> sub git_commitdiff {
>>> my $format = shift || 'html';
>>> +
>>> + my $patch_max = gitweb_check_feature('patches');
>>> + if ($format eq 'patch') {
>>> + die_error(403, "Patch view not allowed") unless $patch_max;
>>> + }
>>> +
>>
>> Should you have to pay overhead for the check-feature call even when
>> the $format is not "patch"?
>
> Actually I wasn't sure if I could use my within the if block, and have
> the value visible outside (it's used further down when picking the
> options to pass to format-patch). And since it was used in the second
> patch anyway to choose whether to add the 'patch' link in html view or
> not, I just put it outside the block.
You have to use _declaration_ ourside block, but assignment can happen
inside:
+ my $patch_max;
+ if ($format eq 'patch') {
+ $patch_max = gitweb_check_feature('patches');
+ die_error(403, "Patch view not allowed") unless $patch_max;
+ }
(Side note: doesn't it uses spaces instead of tabs for align?)
[...]
>> Other than that the patch seems quite straightforward and was a pleasant
>> read. Thanks.
BTW. I'll try to review patch (and probably Ack) soon.
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2008-12-04 1:50 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-03 22:59 [RFCv3 0/2] gitweb: patch view Giuseppe Bilotta
2008-12-03 22:59 ` [RFCv3 1/2] gitweb: add " Giuseppe Bilotta
2008-12-03 22:59 ` [RFCv3 2/2] gitweb: links to patch action in commitdiff and shortlog view Giuseppe Bilotta
2008-12-06 0:53 ` Jakub Narebski
2008-12-06 13:25 ` Giuseppe Bilotta
2008-12-06 15:25 ` Jakub Narebski
2008-12-03 23:55 ` [RFCv3 1/2] gitweb: add patch view Junio C Hamano
2008-12-04 0:20 ` Giuseppe Bilotta
2008-12-04 0:40 ` Junio C Hamano
2008-12-04 1:48 ` Jakub Narebski [this message]
2008-12-04 7:24 ` Giuseppe Bilotta
2008-12-06 0:34 ` Jakub Narebski
2008-12-06 0:46 ` Junio C Hamano
2008-12-06 1:09 ` Jakub Narebski
2008-12-06 1:26 ` Junio C Hamano
2008-12-06 13:01 ` Giuseppe Bilotta
2008-12-06 13:10 ` Petr Baudis
2008-12-06 12:34 ` Giuseppe Bilotta
2008-12-06 13:09 ` Jakub Narebski
2008-12-06 13:46 ` Giuseppe Bilotta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200812040249.01374.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=giuseppe.bilotta@gmail.com \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).