Re: kernel.org now has gitweb installed

From: David Woodhouse <dwmw2@infradead.org>
Date: Apr 28, 2005, 22:12 UTC
Message-ID: <1114726373.2734.47.camel@localhost.localdomain>
In-Reply-To: <42715B30.6010705@zytor.com>

On Thu, 2005-04-28 at 14:52 -0700, H. Peter Anvin wrote:

Show 8 quoted lines

> I thought about this for a few seconds (I really should do that more 
> often...) and realized what it is you want: you want a primary search 
> criterion which is "when did event X become visible to me", where "me" 
> in this case is the web tool.  That is not repository information, but 
> it is perfectly possible for the webtool to be aware of what it has 
> previously seen and when.
> 
> And yes, this ordering is clearly different for each observer.

The mailing list does it with tags -- it remembers the 'last seen commit' and then effectively does 'rev-tree HEAD ^LASTSEEN', except that I make a primitive attempt to get the ordering a little better than what I get from rev-tree. But since the mailing list runs are hourly, I really can get away with a _primitive_ attempt. That's why I hadn't noticed the local/remote ordering problem that Linus pointed out.

It's not clear how you'd attempt to track local history for the general case though -- the whole concept of a 'local' branch being special is anathema to git. You'd have to hack it into some auxiliary storage, as I do with tags -- but to get a fullly correct ordering it'd have to track at least every locally-performed merge, and you really don't want to be doing that kind of thing.

You might perhaps attempt to find a path through the graph which takes in as many commits as possible where committer == `logname`@`hostname` -- but as Linus and I already said, that's expensive.

I'm not entirely sure what the answer is; but it isn't parent ordering and it isn't dates.

Using dates might be a nice quick approximation, but that really isn't good enough.

I wonder if we could try to enforce some meaning for dates though.... Currently, 'rev-tree AAAA ^BBBB' has to build the _entire_ tree for BBBB back to the beginning, so it knows where to stop when following AAAA.

However, if we _do_ take Junio's suggesting of enforcing monotonicity, then we'll always know that the parents of a given commit will have a timestamp which is older than its own timestamp.

So given the task "list commits between 2.6.12-rc3 and 2.6.12-rc4' we could look at the timestamp of rc3, and immediately follow the rc4 parents until we start seeing commits which are older than rc3. Then each time we hit a commit in the parents of rc4 which is older than rc3 is, we continue doing a breadth-first search from rc3 until all the parents we're looking at are older than the parent of rc4 which we're currently considering. Etc.

That means that the common case of "in A but not in B" can at least be handled relatively efficiently without having to wait while it tracks the history all the way back to the beginning. I still don't like it much though...

-- 
dwmw2