From: Linus Torvalds <torvalds@osdl.org>
Date: Thu, 28 Apr 2005 22:04:56 GMT
Subject: Re: kernel.org now has gitweb installed
Message-ID: <Pine.LNX.4.58.0504281451320.18901@ppc970.osdl.org>
In-Reply-To: <7voeby60fp.fsf@assigned-by-dhcp.cox.net>



On Thu, 28 Apr 2005, Junio C Hamano wrote:
> 
> If that is really the case, shouldn't we do one of the
> following:

No. It's not the case that time-stamps are meaningless. 

The thing about distributed stuff is that time gets "fuzzy". It doesn't go 
away. It's still very valid to say "this was done yesterday".

But what gets fuzzy is "before" and "after". For two reasons:

 - time isn't synchronized, and clocks can be off. Usually by just a 
   little bit, but sometimes you'll find just plain badly maintained 
   machines, and time can be a year or two off.

   Ergo: time is a _hint_. It's usually a pretty good hint, but it's a 
   hint.

 - the "parent" relationship is the only "hard" before/after thing that 
   git knows about, but it ignores a lot of real-world interaction, so
   thinking that it is the _only_ before/after measure is ignoring all the
   other communication in a system.

   So parenthood guarantees that something happened "before", but _not_ 
   being directly related doesn't mean that they were totally independent. 
   There's no fixed "speed of light" that defines some absolute "cone of 
   reachability".

So time is relevant, but it's more of a hint than anything absolute. 
Anything that -depends- on time is a bug waiting to happen, but something 
that uses time to visualize things makes sense.

The big advantage with time is that it's cheap. If you want to do a full 
reachability analysis, you have to look at the whole revision tree. That's 
quite possible RIGHT NOW, but it simply ill not be practical in a year, 
when we have 15,000 commits.

So "time" ends up being an approximation for "doing it right".

As an example: it's quite expensive to ask "was this commit part of 
2.6.12-rc3?" because that involves knowing the whole set of commits 
involved in 2.6.12-rc3. Which in turn involves walking the whole revision 
tree starting at 2.6.12-rc3 downwards. 

That's exactly what "rev-tree" does, though. "rev-tree" will do the whole
reachability thing, and as a result you can see whether something was in
2.6.12-rc3 or not. But just for fun - time how long it takes for
"rev-tree" to output its first entry, and how long it takes for "rev-list"
to print its first line. 

Hint: do it with a cold-cache "sparse" tree. "rev-list" will start
outputting data immediately, and work it out as it goes along. "rev-tree"  
will think for some time, and then blast the data out.

In other words: rev-list is what you want for something like "git log", 
because you care about _latency_ of the result.

And that's why it uses time. It's an approximation, but it is an 
approximation that has meaning in real life.

		Linus