restore exercise: git log --all behaves strange

[JKrag]

log --all shows commits in odd order, where the tagged commit is shown in the middle.

Investigate why, and find a fix?

[JKrag]

More info:

git log --graph or even git log --al --graph prints out the commits in the following (correct) order:

* commit 1f057d530ef1757ed7b17ae80d1c6f46e0e9d8b1 (HEAD -> master)
| Author: Jan Krag <jan.krag@eficode.com>
| Date:   Mon Jan 9 14:06:47 2023 +0100
|
|     Update foo.txt
|
* commit 6a2d931c1a5d657be0cb29c12847666b1abc8a5c
| Author: Jan Krag <jan.krag@eficode.com>
| Date:   Mon Jan 9 14:06:47 2023 +0100
|
|     Add bar.txt
|
* commit 2782d518e0c6a9b9875796dd8ed85a02265d267a (tag: v1.0.0)
  Author: Jan Krag <jan.krag@eficode.com>
  Date:   Mon Jan 9 14:06:47 2023 +0100

      Add foo.txt

But running git log --all without ordering prints out the commits in a weird order where the middle add bar.txt commit is printed before after its own parent.

commit 1f057d530ef1757ed7b17ae80d1c6f46e0e9d8b1 (HEAD -> master)
Author: Jan Krag <jan.krag@eficode.com>
Date:   Mon Jan 9 14:06:47 2023 +0100

    Update foo.txt

commit 2782d518e0c6a9b9875796dd8ed85a02265d267a (tag: v1.0.0)
Author: Jan Krag <jan.krag@eficode.com>
Date:   Mon Jan 9 14:06:47 2023 +0100

    Add foo.txt

commit 6a2d931c1a5d657be0cb29c12847666b1abc8a5c
Author: Jan Krag <jan.krag@eficode.com>
Date:   Mon Jan 9 14:06:47 2023 +0100

    Add bar.txt

[JKrag]

This is not due to a difference between --date-order and --topo-order as adding any of these to the --all version returns the output to the "correct" order.

[JKrag]

After thinking hard about this and re-reading the git log docs, I arrived at the theory that this is a side-effect of the setup being scripted, which results in a git-repo where all 3 commits are made in the same second and thus have the same unix timestamp. This means that git log --all finds all refs (here HEAD->master and tag:v1.0.0) and lists those commits (probably as returned by git rev-list --all) followed by their parents in "reverse chronological order", finds no reason to reorder the commits.

I tested this theory by adding a sleep 1 after each commit in the setup.sh script, and then it behaved much more natural.

I don't think I will actually fix anything in the exercise, as:

a) it is not actually problematic for solving the exercise and
b) We don't actually suggest or mention git log --all in the exercise README.

This was just weird behaviour seen and mentioned by a participant during a in-person training session, so I created the bug-report to remind myself to investigate later. Now that I have done that, I understand that this is a small corner case that few people will run into and even fewer will actually notice and be confused by, so it is not really worth annoying everyone with sleep delays in the setup.

Since I am not changing anything, there is no change/PR to review, but maybe some others would like to "review" my conclusion before I close the issue? (pinging @sofusalbertsen @zanderhavgaard )