>
>
> 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@vger.kernel.org
> More majordomo info at
http://vger.kernel.org/majordomo-info.html
>
