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
I'm a bit surprised to find such a fundamently issue in this prominent feature - or is this a recent regression of the UI?
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
Is this a bug or a really weird feature ?