Re: New features in gitk

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Nov 2, 2007, 15:42 UTC
Message-ID: <alpine.LFD.0.999.0711020828440.3342@woody.linux-foundation.org>
In-Reply-To: <e5bfff550711020544h1e9a648apfd268eb549645ccc@mail.gmail.com>

On Fri, 2 Nov 2007, Marco Costalba wrote:

Show 7 quoted lines

> 
> I have tried to overcome --topo-order in qgit but I found it very
> difficult, too much for me.
> 
> Lazily drawing the layout it doesn't mean that you lazy load the data
> from git, indeed you load all the git-log output as soon as it
> arrives.

Would it be more palatable if I tried to write some visualization-specific front-end that acted kind of like "git rev-list", but would have some way of "resetting" its output?

The thing is, I'm pretty sure I can feed you commits really quickly if I don't sort them, and if I don't do the full and careful "oops, this commit was reachable from a commit that was marked uninteresting", but while the fast-and-stupid approach will work well enough for most things, it will occasionally get the wrong answer.

But it will *notice* when it gets the wrong answer, though, and can reset and start over!

IOW, I might be able to do something that

 - prints out the commit info per line

 - prepends each line with a line number

 - goes back to an earlier line 'n' when it notices that it needs to 
   output a commit before a previous commit (or when it notices that a 
   commit that it had already output was actually not supposed to show up)

and with something like that, I could make git give you incremental output.

The thing is, any revision information that requires "global knowledge" simply cannot scale. And "git rev-list --topo-order" may be fast as hell, and I can do it in one second on the kernel archive on my machine, but that's really only true when it's all cached.

If it's not cached, it will inevitably have to read in every single commit if you want a "final and unchanging ordering". Which inevitably gets you a really irritating startup latency. That's just fundamental.

On the other hand, if there is some way to say "oops, restart", I can optimistically give you a list that is always properly sorted on a *local* scale, but then based on later data I might notice that it wasn't right globally and that I need to re-do all or part of it.

But as mentioned, that requires that side-band data of "uhhuh, I screwed up, let me go back and fix it".

			Linus