Broken ordering of commits in PRs

We just realised that commits in a pull requests are visualized in the chronological order of their creation, rather than their actual commit order in the branch that should be merged. See vs.

I’m a bit surprised to find such a fundamently issue in this prominent feature - or is this a recent regression of the UI?


The order of creation === the order of how they should be merged? Or am I seeing something wrong here?

When merging a branch, the actual order in that branch defines the merging order. That may differ (like in this case) from the creation order of a commit if you used git rebase on that branch prior to publishing it. That’s in fact a pretty common workflow when designing clean patch queues in a logical (rather than just chronological) order.


It also has been hapenning to me for at least a few days. Fixing up old commits makes the visual order in github wrong. Hope this problem resolves soon.

I’ve ran into this issue a number of times.  It’s quite frustrating to organize a large change into a sequence of small logical steps only to have those steps displayed in the wrong order on the PR.  Any chance of this getting addressed by github?

I agree that the actual tree structure is more important than the timestamp of the commits, it’s possible to change the commit date doing rebases, corrections and cherry-picks, but they should follow the tree structure and not a timestamp flow.

It’s really sad when rewriting your commit history via git rebase or a force push in a PR, to notice that your commit sequence is out of order, its really hard for us as developers to follow timestamp flow to review commits, seriously! Every time that I try to review commits out of order I lost part of my hair soul.

Is this a bug or a really weird feature ?





Yes, I was surprised that BitBucket does better in that respect - not only ordering the commits, but also representing the commits as a graph. Have a look at as an example.