GitLab version history?

Unfortunately that still doesn’t pick up the proper timeline for the appearance of these two:

It doesn’t use any data source other than commit date for ordering between submodules yet.

Squash the commits

That doesn’t cause the commits to get out of order, so certainly is not happening in all cases.

That doesn’t cause the commits to get out of order, so certainly is not happening in all cases.

No, that’s just an artifact of de-centralised working. The fact that that the earlier commit didn’t appear on the public repo until after the latter just means it wasn’t pushed until that point. Assume the following sequence of events:

23rd June: Developer A syncs local copy of repo with remote.
24th June: Developer A commits change to local repo.
25th June: Developer A goes on holiday.
28th June: Developer B commits to their own local (synchronised) copy of repo, and pushes result to public repo. Latter commit is now publicly visible.
30th June: Developer A comes back from holiday, performs a ‘pull’ of the remote. Assuming there’s no clash in the files changed, git will just perform a ‘FF Merge’, so the commits will appear in date order.
1st July: Developer A pushes local changes to public repo. Earlier commit is now visible in public repo.

The commit order reflects the order in which work was done, just not necessarily the order in which it was publicly available. The alternative is to use rebase on all pull/merge operations, but there’s arguments against that, as well. What you ideally want is more granular push tracking, but that’s something no git implementations seem to do very well.

I have tried using the date of the tags to provide the correct order, the result is in the all-commits2 branch. I suspect only Ben Avison’s cross compile changes have the wrong date as they are not tagged.

That looks rather helpful – many thanks.