Re: Can I have this, pretty please?

Uwe Kleine-König [off-list ref] writes:

David Kastrup wrote:

quoted

Linus Torvalds [off-list ref] writes:

quoted

On Sun, 12 Aug 2007, Linus Torvalds wrote:

quoted

A newsreader is mis-designed for all the same reasons SVN is misdesigned: 
it sees the messages (commits) as a _tree_.

Side note: the lack of this bug is what makes showing large
histories graphically be expensive in the first place.

Not really.

dak@lola:/home/tmp/emacs$ time git-rev-list --parents --topo-order --all>/dev/null

real    0m9.042s
user    0m8.801s
sys     0m0.168s

This does not even start to _think_ of swapping.

rev-list doesn't try to draw a line from each commit to its parents.

Well, that's what --topo-order is somewhat about, but it might
actually not do much together with --all.

That's the really intensive part.  So when gitk reads

	d56871cb0e6ceeca8e5435ff95409d78bed014f0 a046fe0cb8697bc97993b2e609688ff5e89e3e9

it must remember this line at least until it sees a line starting with
a046fe0cb8697bc97993b2e609688ff5e89e3e9.

20 bytes of payload for a commit number.  Make a usable hashing data
structure for it, adds perhaps another 20 bytes.  Links to all parents
are 4 bytes each.  All in all, we won't need more than 64 bytes per
commit.  Take 100000 of them, and you are at 6.4MB.  And that is not
taking into account that you can let git-name-rev cut the information
retrieval down much much more, and just get the rest of the
information when it is actually moved on-screen.  I don't actually
_want_ to see 50 parallel lines from bottom to top of screen obscuring
my branch display and taking away all the screen estate: that is
completely useless information.  Pack the branches away into a cable
pipe and let them come out isolated again only when they are actually
involved on the screen.

There is no necessity to prerender/layout 50 yards of graphing.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

On Sun, 12 Aug 2007, David Kastrup wrote:

quoted

rev-list doesn't try to draw a line from each commit to its parents.

Well, that's what --topo-order is somewhat about, but it might
actually not do much together with --all.

No, --topo-order works with --all too. In fact, to some degree, it's 
*especially* useful with --all, since having multiple tips makes the whole 
topological sort all the more interesting, and also usually makes the end 
result more interesting (ie it's often much more interestign to visualize 
two or more branches together, just to see the *relationships* between the 
branches, and see what is shared.

And yes, it keeps track of every single commit, and computes the 
relationships between them. So it does indeed "draw the line", except it 
can do so in a rather dense and optimized set of data structures.

(That's one reason I love coding in C: it may be more effort, but you can 
tune your data structures in ways you seldom can in higher-level 
languages, and git-rev-list and the object representation is some of the 
most tuned code in git).

20 bytes of payload for a commit number.  Make a usable hashing data
structure for it, adds perhaps another 20 bytes.  Links to all parents
are 4 bytes each.  All in all, we won't need more than 64 bytes per
commit.

Yeah, that's the rough ballpark (except for 64-bit architectures, the 
links are all 8 bytes, but we're pretty careful). See "object.h" for most 
of the details.

			Linus