Enforcing logical order of chronologically incoherent commits in Github

Github’s pull request interface has the somewhat unexpected tendency to show your commit history in a different order than what otherwise appears when running git log.

Imagine the following master and feature branches.

The master branch has 1 commit that adds 1 file named file 0 as shown in the following output:

The commit was made Tue Apr 4 2019 at 00:00:00.

The feature branch, based off of master and subject of our upcoming PR, adds 4 more files, starting with file 3, followed by file 1, file 2, file 4 and finally file 5:

We can see that each commit was made 1 hour appart from each other, starting at 1am with file #3 and finishing at 5am with file #5.

Now imagine we wish to organize our commits such that our file #0 through file #5 are commited in ascending order.

We can achieves this using an interactive rebase of our feature branch:

This command opens up our text editor for us to re-organize our commits:

Which we do, in the following order:

After applying our rebase we can check the final result and see that our commits are now in a more logical order, with file #1 through file #5 committed in order:

After pushing our feature branch to Github, we can create a pull request:

And, as one would expect, our commits show up in ascending order, just like we saw with git log.

However, upon submitting the PR, the commits are back in the original, chronological, order:

This wasn’t expected.

From a reviewer’s perspective, the chronology, the time and date a specific feature was born, matter less than its logical, intuitive ordering. Not only that, but, a pull request doesn’t only pertain to the code itself. It is also about its organization in the VCS and how it affects the repository tree.

Github, by showing commits in their chronological order, which isn’t what git log utimately output, which also isn’t what Github’s pull request submission interface itself shows, complicates the life of both the developer and the reviewer.

They do, however, address this issue in their FAQ; unfortunately, the proposed solution isn’t of much help:

"" If you always want to see commits in order, we recommend not using git rebase. ""

Well, thanks Github, but that is not an option!

The exercise is left to us to figure out.

So here’s a solution: change the authoring date of each of your commits such that the chronological authoring matches the logical ordering.

That is, so that each commit’s authoring date is always in the future relative to its parent authoring date.

One way to achieve this in an automated manner is to use the --exec parameter of git rebase:

Which will open your text editor and execute the following rebase:

Each exec line will execute git commit --amend --no-edit --date="now" && sleep 1 after each commit rebase.

git commit --amend --no-edit --date="now" effectively changes the authoring date of the commit to now.

sleep 1 is my way of ensuring that no commit ends up with the same date and time. git rebase being really fast, multiple commits would end up with the same authoring date, leading to Github showing the commits in yet another random order.

We can verify the dates correctly changed:

Once the rebase is applied, you can push your branch and submit a PR.

If you already pushed your branch, force pushing it will also work and reloading Github’s interface will show the commits in the right order.

Happy reviewing!