[PATCH RFC] pullrequest: reverse order of changeset list

Mads Kiilerich mads at kiilerich.com
Sun Apr 26 16:38:15 EDT 2015

On 04/26/2015 09:22 PM, Thomas De Schampheleire wrote:
> I don't think we need to be able to show lists in both orders. But I 
> do think that we should not assume that users remember which order 
> Kallithea uses, because there are other tools (like Bitbucket) that 
> show pullrequest commits in the other order. Clarifying in some way 
> what the order is, is sufficient to handle this.

In that case it just has to be something that gives the answer when 
someone is looking for it. It could be an explanation as mouse over text 
on the whole graph. Or even better: it could be highlighting the parents 
when hovering over a changeset and/or a bubble that points at the 
direction of the parents and the direction where they can be found (with 
links to the changeset if it for some reason not is shown - for example 
when on a paged changelog).

>> The dots/circles for all changesets could perhaps be made something that
>> looks more like a funnel where the lines from the previous changesets goes
>> into the funnel. Or something like a box where it is clear that the
>> ancestors goes into it while it is the whole thing that is used as an
>> ancestor for other changesets.
>> 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. I still think it is a bad idea
>> to show it top-down.
> I like this idea: it's indeed simple, both to implement and to understand.
> No worries, I'll keep the existing order ;-)
> But to be clear: what do you consider number 1: the parent-most commit
> (the one at the bottom), right?

Yes, that is the first changeset in the series and the first that will 
be applied - let's call that number 1. That reasoning also makes it hard 
to argue that we sould be zero indexed ;-)


More information about the kallithea-general mailing list