Skip to content

Resolve "Wrong sorting of commit order in MR view?"

!4052 (merged) 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.)

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:

$ 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

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

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 (closed)

Merge request reports

Loading