threads / discuss / 40262

Default ordering of git log output

Subject: Default ordering of git log output

## tl;dr

2 messages between Sep 3, 2015 and Sep 3, 2015.

replies: 1people: 2as markdown or json

Kirill Likhodedov· Sep 3, 2015, 13:50 UTC · lore
Is it intended behavior that the default git log output (without ordering parameters) can show parents before children? 
The man says:
    Commit Ordering
       By default, the commits are shown in reverse chronological order.
so it tells nothing about parent-to-child relationship.
I‘ve just faced an example in an open source repository, where I reproduced this behavior: a parent is shown before its child. (so if this behavior is not intended I can give the project URL for debugging)
So could you please clarify:
1. Is it true that the rule "no parents before all of its children are shown” is not guaranteed for default ordering?
2. What does "reverse chronological order” mean? How commits are actually sorted in git log? 
// I was always under impression that git log lists commit in the order in which they are “recorded" to the repository (e.g. pulled), since this seems to be both the fastest way, and also pretty acceptable from the ordering point of view.  

Thanks a lot! -- Kirill.

Junio C Hamano· Sep 3, 2015, 16:43 UTC · re: Kirill Likhodedov · lore

Re: Default ordering of git log output

Kirill Likhodedov <kirill.likhodedov@gmail.com> writes:
Show 7 quoted lines
> Is it intended behavior that the default git log output (without
> ordering parameters) can show parents before children?
>
> The man says:
>     Commit Ordering
>        By default, the commits are shown in reverse chronological order.
> so it tells nothing about parent-to-child relationship.

When you do not give order and when your traversal is not "limited" (i.e. you do not specify A in "git log A..B" that tells us where the traversal ends in topological sense), the traversal "git log" goes:

 - We put HEAD to a queue that holds commits that are further to be
   processed.
 - We pick up the youngest commit from the queue; we show it, and
   push its parents that haven't been shown to the queue.  We repeat
   this step until the queue runs out items.

Your history, when a project participant uses a broken clock to record the committer timestamp, could look like this (topology flows from left to right):

           1---5---6
          /   /
     2---3---4

where the labels in the illustration depict the relative order of their committer timestamps. Imagine your HEAD is at '6'.

So "git log" would do
    Queue       Action
    6           show 6, push 5 to the queue
    5           show 6, push 1 and 4 to the queue
    4 1         show 4, push 3 to the queue
    3 1         show 3, push 2 to the queue
    2 1         show 2; nothing pushed (as it is root)
    1           show 1; nothing is pushed (as its parent 3 has
                        already been shown)
    -empty-

← back to recent threads