[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 ;-)
/Mads
More information about the kallithea-general
mailing list