Git identical timestamps + tags can cause out of order commits from git log

If multiple commits are created with the same timestamp, either via 'git-svn dcommit' when there is more than one commit outstanding, or when using 'git rebase -i' to rewrite multiple changesets, if one of those commits is given a tag (or possibly a branch), git log is prone to reporting them out of order. Because the SourceTree log relies on a child commit being reported before its parent, this can cause incorrect graph rendering.

A workaround for this is simply to select 'Ancestor Order' in the log options. This option is slower than the date order though, which is why it is not the default.

It would be nice to be able to detect this case and auto-enable the Ancestor Order option, although this will require the log to be completely refreshed. You can't actually tell that it's happened until you see a case where a parent commit has already been encountered by the time the child commit referring to it appears. Therefore we'd need to keep a running record of all the SHAs encountered so far. All these things have a performance impact which will need to be assessed, given that this doesn't happen very often and that the user can easily work around it with the Ancestor Order option already.

The other option might be to find a set of git log options which doesn't use --topo-order all the time but also doesn't report the commits out of order in this case. This will need to be carefully examined since the current commands issued already cope with a number of edge cases.