git 1.7.1 commits appear out of order

Question

The following post applies to an obsolete version of Git (version 1.7.1 -- the default on Centos 6) which dates back to 2010. While the obvious answer would be to simply upgrade git (I favor this course of action) I have just joined this project and the team lead is concerned about stability. I suspect Git 1.7.1 is horribly broken and hope to make the case for upgrading.

I have just made my first a commit to a project that I have just joined and was surprised to find that git log inserts my changes before recent commits made by me (SA) -- with the additional complication that TortoiseGit attributes changes made by someone else (MH) to me.

git log --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"

Result:

* SA committed 3d67c9dd4 on Mon Feb 18 12:42:24 2019 +0000      ## SECOND COMMIT
*   SA committed d6f0c4712 on Mon Feb 18 10:55:42 2019 +0000    ## FIRST PUSH (2 mins after FIRST COMMIT)
|\
| * MH committed c1ad3c336 on Thu Feb 14 17:07:01 2019 +0000
| * MH committed 7442f95dd on Thu Feb 14 15:03:46 2019 +0000
| * MH committed 417dc55e2 on Thu Feb 14 11:28:40 2019 +0000
| * MH committed 0eea851b1 on Thu Feb 14 11:27:01 2019 +0000
| * MH committed 72e0fa612 on Wed Feb 13 17:15:22 2019 +0000
| * MH committed 0e80cc9d6 on Wed Feb 13 17:06:50 2019 +0000
| * MH committed ac37fdf64 on Wed Feb 13 17:04:46 2019 +0000
| * MH committed cb1b84489 on Wed Feb 13 17:04:18 2019 +0000
| * MH committed f5026eee5 on Wed Feb 13 15:03:50 2019 +0000
| * MH committed 1ca37588f on Wed Feb 13 15:01:55 2019 +0000
| * MH committed cedcefd36 on Wed Feb 13 12:23:03 2019 +0000
| * MH committed 0bbd26524 on Wed Feb 13 08:39:33 2019 +0000
| *   MH committed db8b7672c on Thu Feb 7 17:41:56 2019 +0000
| |\
| | * MH committed fca13dfe3 on Thu Feb 7 17:36:05 2019 +0000
| | * MH committed 704e2f3ff on Thu Feb 7 17:35:30 2019 +0000
| * | MH committed 1b34e745c on Thu Feb 7 17:41:20 2019 +0000  #### out of place
| |/
| * MH committed f77456930 on Wed Feb 6 11:43:29 2019 +0000
| * MH committed eb9849449 on Tue Feb 5 17:52:17 2019 +0000
| * MH committed 889f94b00 on Tue Feb 5 15:45:19 2019 +0000
| * MH committed ae4505a10 on Tue Feb 5 13:47:42 2019 +0000
| * MH committed 561c703b6 on Tue Feb 5 13:47:07 2019 +0000
| * MH committed 43b4941f8 on Tue Feb 5 13:45:01 2019 +0000
* | SA committed 2336ac0c7 on Mon Feb 18 10:53:49 2019 +0000  ## FIRST COMMIT -- sandwiched BETWEEN earlier commits!!!
|/
* MH committed 87fcf83a2 on Mon Feb 4 11:25:38 2019 +0000
* MH committed ea096edd3 on Fri Feb 1 17:12:01 2019 +0000
* MH committed c51cd83d3 on Fri Feb 1 10:27:52 2019 +0000

Is this a known issue with git 1.7.1?

Update: I've just noticed that the commits made by MH are also out of place, and what looks like branches in the tree are a complete mystery. All changes were made on a the same branch.

Update 2 The confusing commits seemingly attributed to me (by TortoiseGit on d6f0c4712) is in fact the "diff with parent 1" (whatever that means). My actual commits are listed way below as "diff with parent 2".

Answer 1

TL;DR

git log --date-order

or

git log --date-order --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"

Details

I was able to reproduce your scenario on a CentOS 6 machine with Git 1.7.1. (We have a more recent Git on it too, but the 1.7.1 version is still there.)

When there is a merge commit, Git (new and old) seems to consider the branch that got merged in as more "recent", which makes sense if you think of it this way: I made a change on my branch, then I merged in someone else's change, so that's the last thing that happened.

The simple solution is to provide --date-order to git log.

Date order:

$ git log --date-order --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"
*   j committed c767018 on Tue Feb 19 06:40:26 2019 -0500
|\
* | j committed f0fe88c on Tue Feb 19 06:40:10 2019 -0500
| * j committed 29b783b on Tue Feb 19 06:39:55 2019 -0500
|/
*   j committed c592f81 on Tue Feb 19 06:34:38 2019 -0500

Not date order:

$ git log --graph --oneline --decorate --pretty=format:"%cn committed %h on %cd"
*   j committed c767018 on Tue Feb 19 06:40:26 2019 -0500
|\
| * j committed 29b783b on Tue Feb 19 06:39:55 2019 -0500
* | j committed f0fe88c on Tue Feb 19 06:40:10 2019 -0500
|/
*   j committed c592f81 on Tue Feb 19 06:34:38 2019 -0500

A note about all those merge bubbles

In my workflow, I don't like seeing all those merge bubbles in the history. When I merge a feature branch or a bug branch in, I want to see that as a merge, but when it's just changes on master that I have not pushed yet, I try to avoid it. Your note under "Update" suggests you don't like it either, so here's my take on it.

When you do a git pull and there are local commits that were not pushed yet, by default Git (old and new) will merge the remote changes into your local branch, creating a bubble like I recreated above and like your history shows.

To avoid these, use git pull --rebase instead.

My preferred workflow: use git fetch, then inspect the differences between your local branch and origin by adding --all to your git log command, then git rebase origin when you're satisfied it's OK to do so.

git fetch
git log --all --date-order --graph --oneline --decorate ...

or

git log master origin/master --date-order --graph  --online --decorate ...

then

git rebase origin

The usual caveat about rebasing applies: avoid rebasing anything you've pushed before. This is a good idea for local commits that exist in your sandbox only.