The current implementation of the log uses a BFS algorithm to crawl the history, which makes the order in which the revisions are output counter-intuitive.
For instance:
0c86a6b has parents b620fd2 a13e8d4
b620fd2 has parents adb072d db0267e
a13e8d4 has parents b48b1f7 33ddd81
the revisions therefore show in the order:
- 0c86a6b
- b620fd2
- a13e8d4
- adb072d
- db0267e
- b48b1f7
- 33ddd81
Which is algorithmically correct, and lets us keep a reasonable heuristic to truncate the history ("only go $n levels deep"), but is confusing to users.
A few options are available to fix this issue:
- Forgoing the graph order completely and just showing the revisions in reverse chronological order (GitHub, GitLab and Phabricator use this approach).
- Building a "rail track" to show branching and merging (Kallithea and bitbucket use this approach).
Both of those options will require some smarter way to walk the history graph than just a plain stupid BFS.