Re: kernel.org now has gitweb installed

[David Woodhouse <dwmw2@infradead.org>]

On Thu, 2005-04-28 at 14:52 -0700, H. Peter Anvin wrote:
> 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