Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The <a href="http://git-scm.com/docs/gitk" rel="nofollow noreferrer"><code>man gitk</code></a> at least mentions it does take the same options than <strong><a href="http://git-scm.com/docs/git-rev-list" rel="nofollow noreferrer"><code>git rev-list</code></a></strong>, including</p> <pre><code>--date-order </code></pre> <blockquote> <p>This option is similar to <code>--topo-order</code> in the sense that no parent comes before all of its children, but otherwise things are still ordered in the commit timestamp order. </p> </blockquote> <p>See "<a href="https://stackoverflow.com/questions/1570535/guide-to-understanding-gitk">Guide to understanding gitk?</a>" for more.</p> <hr> <p>Note: if <code>-d</code> or <code>--date-order</code> is really the argument you are after, better not using too much, according to Linus himself (from <a href="http://lists-archives.com/git/655429-visualizing-git-s-git-repo.html" rel="nofollow noreferrer">lists-archives.com/git</a> or <a href="http://www.spinics.net/lists/git/msg67309.html" rel="nofollow noreferrer">www.spinics.net/lists/git/</a>):</p> <blockquote> <p>The thing is, <code>--date-order</code> strings out and mixes up the commits on the same development chain, and by doing so it makes the different chains of development much harder to see.<br> It also ends up showing the development in a more "parallel" way, which in turn makes the view even harder to read.</p> <p>So I would suggest not using <code>--date-order</code> by default. It doesn't add anything to any normal flow, and it makes the big picture harder to see.</p> <p>The only time you really want <code>--date-order</code> (or "<code>-d</code>", which is shorthand for it for just <code>gitk</code>) is really</p> <ul> <li>when the big picture is really really simple, and you actually want to see more detail because the big picture is too trivial to even be interesting otherwise.<br> (In other words: <code>--date-order</code> is fine for really simple development where there is only ever just a couple of branches or where you have pruned away so much of the history that the remaining part is simple)</li> <li>when you want to debug "<code>git rev-list</code>" behaviour itself, since the date order actually matters for how git traverses the commit chains.</li> </ul> <p>The second case is something that I suspect nobody but me and a few other people have ever done.<br> I found it very useful together with <code>--show-all</code> when I was debugging the revision walker (see commits "<a href="https://github.com/git/git/commit/3131b713013f06285cad3ffdcc61f417ac4ba158" rel="nofollow noreferrer">Add "<code>--show-all</code>" revision walker flag for debugging</a>" and "<a href="https://github.com/git/git/commit/7d004199d134c9d465e013064f72dbc04507f6c0" rel="nofollow noreferrer">Make revision limiting more robust against occasional bad commit dates </a>", where the first implements <code>--show-all</code>, and the second one is the end result of my debugging).</p> <p>In other words: never start out with "<code>-d</code>" or "<code>--date-order</code>" by default.<br> Only if you have some reason to then think that the view is too simple or you need to drill down into the commit relationships should you use it.</p> </blockquote>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload