-
Merge branch '12724-wrong-sorting-of-commit-order-in-mr-view' into 'master' · e4a1af83Rémy Coutable authored
Resolve "Wrong sorting of commit order in MR view?" !4052 fixed this for the most obvious cases, but there were still some problems. Here's my test case: I have a branch where I was suffering from an unfortunate issue. Every other commit I made had its commit date set to one day before it should have been. (Perhaps my system clock was misbehaving.) ```shell for i in {1..10} do echo $i > $i git add $i GIT_COMMITTER_DATE=`date -v -$((i % 2))d` git commit -m $i done ``` The git CLI still gives me the commits in the right order, but I can see that the timestamps alternate between two values: ```shell $ git log --format='%h %ct %p %s' master...HEAD f0c3108 1463646313 3d38a13 10 3d38a13 1463559913 67f419b 9 67f419b 1463646313 74330c0 8 74330c0 1463559913 56361d7 7 56361d7 1463646313 ba1b60c 6 ba1b60c 1463559913 f91497d 5 f91497d 1463646313 79c5e57 4 79c5e57 1463559913 b953cef 3 b953cef 1463646313 12fc411 2 12fc411 1463559913 835715b 1 ``` Unfortunately, GitLab didn't like this _at all_. Here's what the commits on my MR from that branch looked like: ![image](/uploads/fdc38e932eeedcb77de9ec4b50ad1476/image.png) That's because we were sorting the commits by date, which is safe if they are in that order anyway. If they aren't, then because Ruby's sorting isn't stable, we lose even the ordering among the correctly-ordered commits with the same timestamp. After these changes (and reloading the MR's diff), this looks like: ![image](/uploads/b09fb0f51359c1c89484e713e859512b/image.png) The commits view was also wrong, but in a slightly different way. In table form: | View | Before | After | | --- | --- | --- | | Commit list | 10, 8, 6, 4, 2, 9, 7, 5, 3, 1 | 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 | | MR commits | 10, 2, 8, 4, 6, 5, 7, 3, 9, 1 | 10, 9, 8, 7, 6, 5, 4, 3, 2, 1 | Closes #12724 See merge request !4208
e4a1af83
To find the state of this project's repository at the time of any of these versions, check out
the tags.
×