From: Jakub Narebski <jnareb@gmail.com>
To: "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFCv4 2/3] gitweb: add patches view
Date: Tue, 16 Dec 2008 11:16:44 +0100 [thread overview]
Message-ID: <200812161116.45024.jnareb@gmail.com> (raw)
In-Reply-To: <cb7bb73a0812160149j1dcaefccv1caf4a2e589ffebb@mail.gmail.com>
Giuseppe Bilotta wrote:
> On Tue, Dec 16, 2008 at 4:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sat, 6 Dec 2008 16:02, Giuseppe Bilotta wrote:
>>
>>> The only difference between patch and patches view is in the treatement
>>> of single commits: the former only displays a single patch, whereas the
>>> latter displays a patchset leading to the specified commit.
>>
>> I like that fact that we have "patches" action which intent is to
>> show series of patches, and "patch" action which intent is to show
>> single patch. I'm just not sure if "patch" view should not simply
>> ignore $hash_parent...
>
> I had doubts on this myself. In the end I decided to make patch
> consider hash_parent if present because IMO it's what a user would
> expect in case e.g. of hand-crafted URLs.
Ah. I can understand that.
[...]
>>> sub git_commitdiff {
>>> my $format = shift || 'html';
>>> + # for patch view: should we limit ourselves to a single patch
>>> + # if only a single commit is passed?
>>> + my $single_patch = shift && 1;
>>
>> What does this "shift && 1" does? Equivalent of "!!shift"?
>> Is it really needed?
>>
>> Perhaps it would be better to use %opts trick, like for some other
>> gitweb subroutines (-single=>1, or -single_patch=>1, or -nmax=>1)?
>> Or perhaps not...
>
> It would be MUCH better, I'll do it this way. I'll pass the -single
> param in both cases, having value true/false, even though the false
> case is not needed since undef is false in perl anyway. (I like
> symmetry.)
--
Jakub Narebski
Poland
next prev parent reply other threads:[~2008-12-16 10:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-06 15:02 [RFCv4 0/3] gitweb: patch view Giuseppe Bilotta
2008-12-06 15:02 ` [RFCv4 1/3] gitweb: add " Giuseppe Bilotta
2008-12-06 15:02 ` [RFCv4 2/3] gitweb: add patches view Giuseppe Bilotta
2008-12-06 15:02 ` [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views Giuseppe Bilotta
2008-12-16 1:03 ` Jakub Narebski
[not found] ` <cb7bb73a0812160202n1f4f7f4fi7f71455eb42bcd31@mail.gmail.com>
2008-12-16 10:14 ` Jakub Narebski
2008-12-16 11:14 ` Giuseppe Bilotta
2008-12-16 3:14 ` [RFCv4 2/3] gitweb: add patches view Jakub Narebski
[not found] ` <cb7bb73a0812160149j1dcaefccv1caf4a2e589ffebb@mail.gmail.com>
2008-12-16 10:16 ` Jakub Narebski [this message]
2008-12-15 13:17 ` [RFCv4 1/3] gitweb: add patch view Jakub Narebski
2008-12-15 13:48 ` Giuseppe Bilotta
2008-12-15 13:58 ` Jakub Narebski
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=200812161116.45024.jnareb@gmail.com \
--to=jnareb@gmail.com \
--cc=git@vger.kernel.org \
--cc=giuseppe.bilotta@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.