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

[Nick Coghlan]

On 10 March 2015 at 12:35, 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.

I was assuming it would show the linearised branch graph sorted by
date (ala "hg log -G"), unless you filtered it down to a specific
branch. However, while you could use named branches in hg, I'm not
sure what the equivalent would be in git (with the main problem being
how to decide which branch of an ancestral merge to follow)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia