Surely. I am on a bus with terrible WiFi that does not let me use the usual terminal, but you would find a code in revision.c that sets revs->topo_order = 1 when it parses "--graph" option. If you disable it, that would stop "--graph" from wanting to compute the whole history before starting to emit stuff (and then stop at nth one with --max-count). I do not know what other side effects such a change would have, though. On Tue, May 20, 2014 at 5:13 PM, Mitchel Humpherys <mitch.special@xxxxxxxxx> wrote: > On Tue, May 20 2014 at 03:50:43 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Mitchel Humpherys <mitch.special@xxxxxxxxx> writes: >> >>> I've noticed that --max-count doesn't seem to speed up `git log --graph' >>> computation time. >> >> AFAIK, --graph wants to compute the whole history and the max-count >> only affects the output phase after --graph does its computation. >> >> Besides, "log --max-count=n" and "log HEAD~n.." compute completely >> different things, so the comparison is apples and oranges. > > Yes, apples and oranges in a black box :). I provided the > HEAD~n.. measurements just to show that we can get (almost) the exact > same output another way and it's much faster. It just "seems like" > --max-count=n should speed things up as n decreases... > > > -- > Mitch -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html