git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

  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 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).