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

Sun Mar 8 05:26:42 EDT 2015

On Sun, Mar 8, 2015 at 4:20 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 8 March 2015 at 11:30, Mads Kiilerich <mads at kiilerich.com> wrote:
>> On 03/07/2015 08:50 PM, Thomas De Schampheleire wrote:
>>> 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?
>
> Whenever I've wanted to jump to a particular revision in a repo
> history on GitHub, BitBucket or one of the standalone git or Mercurial
> web views, the options I've generally wished for have been:
>
> * jump to the initial commit (usually to see how long the project has
> been around)
> * jump to a particular commit hash (rather than revision number)
> * jump to the first or last commit in a particular date range (e.g. a
> given month)
> * filter the displayed commits by date range, patch submitter, or patch approver
>
> Essentially, I'd like the same kind of capabilities internet banking
> and accounting services give me for financial records, only the
> transactions in this case are making changes to a particular version
> control repository.

For Mercurial, we should add revset filtering to the changelog view.
This could cover most of the filtering requirements.
I'm not sure how this would be handled in git.

Note that I think it should be possible to not just give a revset for
filter, but also give a way to view changesets _around_ a particular
filter. For example, everything 'around' November 5, probably with the
ability to scroll up and down.

>
> Using generic list pagination and guessing appropriate page numbers
> instead has always felt like a rather poor workaround for the lack of
> those jump and filtering capabilities.

True.

>
>>> Or, maybe the user went too far and remembered that on page 3 he had
>>> seen the entry he was looking for but didn't realize it at that time.
>>> Then he could click on '3' from the top.
>>
>> - but paging is usually/always going backwards from the latest revision. The
>> pages are thus a moving target. What was on page 3 will soon be on page 4.
>> And obviously, the page numbers depends on what kind of filtering you are
>> using (currently either everything or just one branch).
>
> Right, this is a large part of why I suspect that the model I envision
> above (where the commit history is conceptually ordered by time and
> there are ways to find suitable "jump targets" and filter the
> displayed activity log) would actually be far more user friendly.
>
> However, it would also be substantially more work to implement, and I
> don't have a good answer for that objection at this point.
>
>>>> (I dislike paging - especially when the items on pages don't have
>>>> "primary
>>>> keys" that gives a natural paging. I would much rather have automatic
>>>> loading of an extra chunk when scrolling to the bottom of the page.)
>>>
>>> I consider this 'an incremental improvement' while we don't yet have
>>> infinite scroll.
>>>
>>> Note that what I dislike about certain implementations of infinite
>>> scroll is the following scenario:
>>>
>>> - scroll through a list using infinite scroll
>>> - click an item and go to a different page
>>> - click 'back' in the browser
>>> - one expects to see the list at the place where we left it, but often
>>> one just gets back the initial list and one has to scroll completely
>>> back, losing track of what you already looked at. Especially for long
>>> lists this is a problem.
>>>
>>> Without a solution to this problem, I prefer paging over infinite
>>> scroll, but if it is possible to handle this problem then I'm fine
>>> with infinite scroll.
>>
>>
>> Good point.
>
> This is also why, despite my comments above about considering
> pagination a poor long term answer from a UX perspective, I think
> "better pagination" is an excellent near term improvement. It's
> already there, it's relatively easy to make it better, so there's no
> reason not to do that while folks ponder the possibilities for more
> substantial improvements.

That was indeed my reasoning. I fully agree that pagination can be
improved by replacing it with infinite scroll (but with correct
history handling), but one extra thought: the behavior should degrade
gracefully when Javascript is disabled. In this case, it probably
means that standard paging would still be available for those users.

>
>> I guess clever web / frontend developers could implement a solution to that.
>> Perhaps something with rewriting the URL when loading more entries so going
>> back to it would make sure the same entries are loaded and shown.
>
> One site I use personally that does that is the FutureWise forums:
> https://forum.futurewise.org.au/t/what-role-should-foss-take-in-government/27
>
> As you scroll down the page, the little "X/Y" counter in the lower
> right updates indicating how far down the page you are in terms of
> "comments seen vs comments posted", and then the URL in the address
> bar also automatically updates to target the anchor for the topmost
> comment currently fully on the screen.
>
> Digging into the technical details, it looks like FutureWise runs
> Discourse: http://www.discourse.org/
>
> The Discourse source code is at https://github.com/discourse/discourse
> The license is GPLv2+
> (https://github.com/discourse/discourse/blob/master/LICENSE.txt)
>
> And what appears to be a good write-up of how it works:
> http://eviltrout.com/2013/02/16/infinite-scrolling-that-works.html

Very interesting. I haven't delved into the Discourse source code yet,
but googling I found this:
http://www.infinite-scroll.com/
https://github.com/infinite-scroll/infinite-scroll
and an improvement:
https://github.com/outdooricon/infinite-scroll-with-history

I haven't checked out all the details yet, and there may be other
things we can start from, but the basic concept looks what we need.

Best regards,
Thomas