On Sun, 28 Oct 2007, Paul Mackerras wrote: > > Yeah. Actually what I'd like is to know how many commits git log is > going to give me That's not known until later. > With --topo-order (or --date-order) it has to get to the last commit > before it outputs the first commit, doesn't it? The cost is not generally in outputting the commits. The real cost is in traversing them in the first place. So yes, we could output the number of commits once we know it, but generally, by that time, it's not an interesting number any more! You might as well just read the list, because git is going to feed it to you as fast as it can (which is plenty fast - you'll probably get hundreds of megabytes of SHA1 values per second at that point). So basically, by the time you start getting SHA1's from --topo-order, the best thing you can do is just lay back and think of England. The *last* thing you want to do is bother with any graphics and updates, because it's just going to slow things down. It's before you even start getting the SHA1's, _or_ if you don't use "--date/topo-order" in the first place, that you want to have a "wait, I'm thinking" thing. And at neither time do you know how long it's going to be. (And as mentioned many times earlier - if you can avoid topo-order and date-order entirely, you are going to perform a million times better at startup for the cold-cache case. Since you seem to be doing the graph layout lazily now, maybe you could aim for that some day? It does mean that you might - occasionally - end up having to add a commit to *before* one you already laid out). Linus - 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
