Re: [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views

[Jakub Narebski <jnareb@gmail.com>]

You lost CC, somehow...

On Tue, 16 Dec 2008, Giuseppe Bilotta wrote:
> On Tue, Dec 16, 2008 at 2:03 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> > On Sat, 6 Dec 2008, Giuseppe Bilotta wrote:


>>> +     if ($patch_max) {
>>> +             if ($patch_max < 0 || @commitlist <= $patch_max) {
>>> +                     $paging_nav .= " &sdot; " .
>>> +                             $cgi->a({-href => href(action=>"patches", -replay=>1)},
>>> +                                     @commitlist > 1 ? "patchset" : "patch");

[...]
>> I wonder if it would make sense to pass
>>
>>   href(..., hash_parent => $commitlist[-1]{'id'}, ...)
>>
>> here. But I think having separate "patches" action, with intent being
>> displaying series of patches, is a better solution. This way you can
>> see in URL and in the page title (thus also in window title, or in
>> bookmark name) if it is single patch or patch series (perhaps consisting
>> of single patch).
> 
> I'm not sure I'm following you here. Do you mean as in manually adding
> the parent endpoint to the URL when it's not specified in the log view
> itself? I think that would change the behaviour for > 100 patches.

First, I meant here that having separate "patches" action is a good
idea in itself, whether we pass explicitly and always $hash_parent
parameter here or not.
 
Second, I haven't thought about interaction with (short)log
pagination; in $patch_max < 0, i.e. unlimited patches, and most
common case of running 'shortlog' action without 'hp' (hash_parent)
limiter used, one would make 'patches' limited to page size,
other unlimited.  On one hand side limiting to page size makes
"patches" be more of equivalent of current "shortlog" view; on the
other hand it makes 'unlimited' actually be limited to page size,
at least in this situation...

-- 
Jakub Narebski
Poland