1489680 - Provide clear indication in lando of the ordering of the stack

Status: NEW

(Conduit :: Lando, enhancement, P3)

Description

[Xidorn Quan [:xidorn] UTC+10]

When I tried Lando Beta, I noticed that the order of revisions are
* bug XXXX part 2
* bug XXXX part 1
or, leaf comes earlier than their ancestors.

Although this matches the order in phabricator, it gives me an impression that part 2 would get landed first.

I would suggest in Lando, the commits should be shown in landing order rather than stacking.

(Actually, it would probably be useful if Phabricator also shown the stack in this order.)

Comment 1

[:glob ✱]

(In reply to Xidorn Quan [:xidorn] UTC+10 from comment #0)
> Although this matches the order in phabricator [..]

source control tools display commits in this order - mercurial (command line and hgweb), git (command line and github).
using the reverse ordering on lando would make it an outlier and likely be more confusing.

there's probably something we can do here to make the ordering clearer (eg. numbering each row with landing order, or providing a clearly labeled toggle between "stack" and "landing" ordering).

Comment 2

[Steven MacLeod [:smacleod]]

The next version of the UI will have a graph which makes the parent/child relationships more obvious, I'll block the story on this bug to track the feedback. Currently the landing preview uses arrows to indicate this relationship, there are a couple things we can do to make it more obvious though.

Comment 3

[Steven MacLeod [:smacleod]]

The work in Bug 1490337 has been de-prioritized and this change didn't make it into the partial implementation. Hopefully the new graph in Bug 1490337 we're about to land will help, but I'm tossing this on the backlog so we can revisit adding more indicators later.

Comment 4

[Steve Fink [:sfink] [:s:]]

Was filing the same bug and found this duplicate. I would also expand the request to include a clearer indication of the ordering of the actions at the top of the screen, though that is much less important because it contains a timestamp. (It's just that if there is to be a visual indicator of patch ordering, then hopefully the same indicator could be used for action ordering. I never think to use the timestamps, and am often confused about what the latest action is.)

One idea I had, which would only apply to the patches, would be to display the base revision that the patches would be applied to -- either the exact current autoland revision, or a symbolic indicator if the base revision is only determined later. I don't really care what ordering is used. Mercurial is inconsistent (you get a different ordering based on command-line parameters, and the hg histedit ordering was confusing enough that I patched the curses version to use a caret to indicate which direction a fold operation goes to.)

Example:

	1655203   Accepted         D84872: Bug 1655203 - Add tests for AutoStableStringChars and deduplication	
	1655203   Accepted         D84877: Bug 1655203 - Reimplement everything
	1655203   Accepted         D72891: Bug 1655203 - Prepare the grounds
        (base)    Base revision    (Current head of autoland tree)

(or the other way around; I still don't remember which way it goes.)

Or even:

	(tip)     New head	   (New head of autoland tree)
	1655203   Accepted         D84872: Bug 1655203 - Add tests for AutoStableStringChars and deduplication	
	1655203   Accepted         D84877: Bug 1655203 - Reimplement everything
	1655203   Accepted         D72891: Bug 1655203 - Prepare the grounds
        (base)    Base revision    (Current head of autoland tree)