On Sun, 12 Aug 2007, David Kastrup wrote: > > > > So, use "git log --pretty=oneline" instead, which doesn't have the > > expense. > > Yes, like managing a manual with grep is all one needs. git log > --pretty=oneline provides just the commit headers, but offers no way > to jump into the commits themselves and back easily. You misunderstand. I was suggesting you do a *tool* that bases its listing on --pretty=oneline, and then goes from there. If you don't show the graph anyway, all the complex and expensive things that "git-rev-list --topo-order" does is pretty much totally useless. You're going to show the commits as a list anyway, and then when you *select* one commit for closer inspection, you can then try to do a better job at that point of doing the reachability (ie parenthood is trivial, and the branch reachability is cheap if it's close to the tip of the tree, which it would almost always be). The real problem with the topological sort is that it requires you to have the full history. That not only makes everything pretty big, it also means that the startup cost is bad, since you can't do things incrementally. But if you have a client that is incremental anyway, almost all of that goes away. 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
