On Tue, Mar 10, 2015 at 3:35 AM, Mads Kiilerich <m...@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 <m...@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 <m...@kiilerich.com> >>>> wrote: >>>>> >>>>> On 03/04/2015 10:06 PM, Thomas De Schampheleire wrote: >>>>>> >>>>>> # HG changeset patch >>>>>> # User Thomas De Schampheleire <thomas.de.schamphele...@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. _______________________________________________ kallithea-general mailing list kallithea-general@sfconservancy.org http://lists.sfconservancy.org/mailman/listinfo/kallithea-general