All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Giuseppe Bilotta" <giuseppe.bilotta@gmail.com>
To: "Jakub Narebski" <jnareb@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [RFCv4 3/3] gitweb: link to patch(es) view from commit and log views
Date: Tue, 16 Dec 2008 12:14:26 +0100	[thread overview]
Message-ID: <cb7bb73a0812160314t4a74dbb3r4748ad9190a88bd6@mail.gmail.com> (raw)
In-Reply-To: <200812161114.35336.jnareb@gmail.com>

On Tue, Dec 16, 2008 at 11:14 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> You lost CC, somehow...

Duh, clicked the wrong button.

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

I'm not too sure about that. Do we pass the actual hash parent, or
just the last patch that would be included due to the patch limit?
This, btw, is an issue that should resolved with patch view: it should
warn when the patch limit is reached before all intended patches are
output. I'm just not sure about how to do it.

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

Consider that switching from log to shortlog view doesn't respect
pagination (e.g. if you're on page 3 of shortlog and click on log you
go to page 1 of log) I would be inclined to keep patches behaviour
independent of log view pagination.


-- 
Giuseppe "Oblomov" Bilotta

  reply	other threads:[~2008-12-16 11:15 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 [this message]
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
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=cb7bb73a0812160314t4a74dbb3r4748ad9190a88bd6@mail.gmail.com \
    --to=giuseppe.bilotta@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jnareb@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.