Incorrect Ordering of Diffs in Interactive Smartlog Timeline with High Volume

[Ankush-lastmile]

trafficstars

The Interactive Smartlog timeline is experiencing an issue with the ordering of diffs, particularly noticeable when handling a large number of entries. This problem primarily affects diffs that are older and are positioned behind the remote/main branch in the timeline.

As a result of this ordering issue, the user experience and the accuracy of the Smartlog's display are affected. To better demonstrate this issue, I've attached an image that shows how the diffs are currently being presented in the timeline. The issue seems to be exacerbated as the volume of diffs increases.

Full SmartLog Time line:

[sggutier]

Thanks for reporting this. I'm not entirely sure what exactly the issue is just by looking at the screenshots, however.

What are the other diffs that are descendants of remote/main in the leftmost branch? Could you please provide us with the output of sl in the terminal as well, so that we can compare that to how ISL renders it?

[Ankush-lastmile]

Hi @sggutier

I've attached a screenshot and annotated it for your convenience.

What are the other diffs that are descendants o

Left is the interactive smartlog rendering, right is the output of sl. All diffs are descendents of main from the past.

I've cleaned up my diff stacks a little bit but some of the renderings still exist

[quark-zju]

This seems like the commit date wasn't parsed correctly. We got a similar report internally but we haven't figured it out yet. If you got a chance, could you share the output of:

sl version
sl log -r . -T '{committerdate} {date}'

?

[alex-statsig]

Hey @quark-zju, we're running into the same intermittent issue (timestamps all say "now" in ISL / inline blame).

I have no issues on versions: extension 0.1.34, sapling 0.2.20231113-145254+995db0d6. However, a coworker repros the issue on: extension 0.1.34 (fixed by downgrading to 0.1.33), sapling 0.2.20230523-092610+f12b7eee.

Here's an affected coworker's output:

 statsig % sl version
Sapling 0.2.20230523-092610+f12b7eee
 statsig % sl log -r . -T '{committerdate} {date}'
 1705710681.028800

So seems you're right, committerdate not available on old versions of sapling, but the new version of extension switches to using that maybe.

[quark-zju]

a coworker repros the issue on: extension 0.1.34 (fixed by downgrading to 0.1.33), sapling 0.2.20230523-092610+f12b7eee.

Thanks for confirming! The solution here is probably upgrading sl. We plan to add some version check in ISL so we can surface warnings about older versions.