[PATCH] pullrequest/compare: add logical changeset index to clarify the order

[Thomas De Schampheleire]

On Fri, May 15, 2015 at 11:26 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 05/13/2015 09:25 PM, Thomas De Schampheleire wrote:
>>
>> # HG changeset patch
>> # User Thomas De Schampheleire <thomas.de.schampheleire at gmail.com>
>> # Date 1431287504 -7200
>> #      Sun May 10 21:51:44 2015 +0200
>> # Node ID e19127e4040d1817bbec77118ca7377644f76a64
>> # Parent  6e8effd028bf41a132aee02e52ffc0bf990dadf4
>> pullrequest/compare: add logical changeset index to clarify the order
>>
>> Is the parent-most changeset in a changeset the one at the top or at the
>> bottom? When the revision numbers are not shown, it is not obvious to
>> determine this.
>>
>> This commit adds a logical changeset index to the commit list in a
>> pullrequest or compare view. The index starts at 1 (the parent-most
>> commit)
>> and has no relation whatsoever with the commit hash or revision number.
>
>
> I don't know about the location in the middle of line next to the hash. How
> about putting it first on the line, next to the graph?
>
> It looks a bit weird when the numbers jump from 9 to 10. Please make all the
> numbers same width and right align them - perhaps by putting them in a
> separate column.

Ok, will fix both things.

>
>
> I'm not sure how much of a win I think it is ... but ok. A mouseover tooltip
> could perhaps explain what the number means - especially if the tip was
> different for the first and last changeset.

I don't really understand what you mean with 'if the tip was different ...'
And also, what kind of explanation would you suggest? Something like:
'Commit 3/10 in this list (ordered from parent to child)' ?

>
> Or could we perhaps just add a line explaining "oldest at bottom, most
> recent on top" before and/or after the list instead of using vertical space
> on every line?

This is an alternative solution that was included in my original patch.

Adding the logical index was actually an idea of yours:
"It would probably be simpler to just put a number on all the
changesets in the series. The number will be local for the PR but it
will be small and the ordering will be obvious (even though the number
itself will be unstable in the case where the topological ordering on
the server somehow should change). I think that would be
upstreamable."
http://lists.sfconservancy.org/pipermail/kallithea-general/2015q2/000780.html

The advantage of an index is that it can easily be referred to in oral
conversations between developers, as opposed to referring to the
changeset hash or commit title.

Best regards,
Thomas