[PATCH] changelog: repeat pager links on top of changelog

[Thomas De Schampheleire]

On Tue, Mar 10, 2015 at 3:35 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 03/08/2015 10:20 AM, Thomas De Schampheleire wrote:
>>
>> On Sun, Mar 8, 2015 at 2:30 AM, Mads Kiilerich <mads at kiilerich.com> wrote:
>>>
>>> On 03/07/2015 08:50 PM, Thomas De Schampheleire wrote:
>>>>
>>>> On Fri, Mar 6, 2015 at 5:29 PM, Mads Kiilerich <mads at kiilerich.com>
>>>> wrote:
>>>>>
>>>>> On 03/04/2015 10:06 PM, Thomas De Schampheleire wrote:
>>>>>>
>>>>>> # HG changeset patch
>>>>>> # User Thomas De Schampheleire <thomas.de.schampheleire at gmail.com>
>>>>>> # Date 1425503195 -3600
>>>>>> #      Wed Mar 04 22:06:35 2015 +0100
>>>>>> # Node ID ed66618ffb23900e1cf56add90f54801e455a0eb
>>>>>> # Parent  297d798bd5b22ea562d0813bed7e5eb6bc646c1b
>>>>>> changelog: repeat pager links on top of changelog
>>>>>>
>>>>>> In particular since the default number of entries in the changelog has
>>>>>> been
>>>>>> increased to 100, having the pager links both above and below the
>>>>>> changelog
>>>>>> is more user-friendly.
>>>>>
>>>>>
>>>>> When will the user ever be looking at the top of a multi-page listing
>>>>> of
>>>>> changesets and without seeing the end of the current page know that he
>>>>> has
>>>>> to navigate to the next one ... or 4 pages forward?
>>>>
>>>> For example because he is trying to find something around a given
>>>> revision number, and uses the first few entries as a key. Based on
>>>> that he can guess how many pages to advance.
>>>
>>>
>>> Mercurial revision numbers are local. Git doesn't really have revision
>>> numbers. Kallithea can be configured to show the server's local revision
>>> numbers but I think these revision numbers are misleading and barely
>>> useful.
>>>
>>> Please consider your example in more details: How did the user end up
>>> with a
>>> revision number? Was it the right one - and by which definition? Wouldn't
>>> it
>>> be better to not show the revision number and thus prevent the user from
>>> being hit by these wrong expectations?
>>
>> Fair enough, replace 'revision number' with 'date' in my scenario..
>
>
> That assumes that history is linear and with monotonically increasing dates?
> That is not the case for the repositories I have seen.
>
> Instead Kallithea usually shows the graph so it is more "obvious" how
> changesets are related. (I guess one reasons I find paging odd for a
> repository is that you can't page a graph - especially because the
> topological sorting is arbitrary. It would make more sense to be able to
> zoom in/out or constrain the view to a subgraph.)
>
> I could see the point in having "pages" where each page was one date if time
> was monotonic (perhaps by using "push" date) ... but that is not what we
> have.
>
> Interesting discussion!
>
> What do others say? How does it work and look for you?
>
> I guess I'm "-0". It takes up some space and leaves less useful information
> "above the fold" and I think it looks a bit odd and I don't think it adds
> much value but it does no harm.

I'm fine with rejecting this patch and wait for a good filtering and
scroll implementation.