Subject: Re: [RFC] origin link for cherry-pick and revert

From: Petr Baudis <[email-masked]>
Date: Wed, 10 Sep 2008 18:40:45 +0200

On Wed, Sep 10, 2008 at 04:16:30PM +0200, Stephen R. van den Berg wrote:
> Theodore Tso wrote:
> >  And the maintenance of this database
> >is purely optional; you only need it if you care about efficiently
> >looking up UUID's, and given "time git log > /dev/null" on the kernel
> >tree only takes six seconds on my laptop, and "git log > /dev/null"
> >only takes 0.148 seconds for e2fsprogs, for many projects you might
> >not even need the database to accelerate lookups via UUID.
> 
> The database needs to be available to anyone doing a clone of the
> repository, which implies that:
> - It needs to be network based.
> - It needs controlled write access (which is a mess).
> - It is slow during blame/gitk operations.
> - It is rather nontrivial to get things setup such that someone (after
>   cloning the repository) is able to run cherry-pick/gitk/blame/revert
>   and have those commands use the database transparently.

The database can just live in a special branch, with trees organized the
same way the object database is, possibly in a more optimized way
(having the HEAD trees cached around inside Git, etc.).  This should be
no rocked science if the design is given a little thought, and should be
fairly fast afterwards.

I'm not endorsing assigning UUIDs to commits now at all (but I don't
have time to formulate a comprehensive argument against that either).

However, having a commit -> nonessential_volatile_metadata database
would be useful for many other things as well! For example amending
commit messages later, maintaining general linkage between related
commits, tracking explicit rename hints for Git (like the Samba guys
would appreciate right now, and me many times in the past - note that
this is NOT the same as directly tricking renames within Git history)
or caching expensive computations with mostly static results (like the
rename detection or maybe pickaxe indexes - that could be quite large,
so we might want to actually separate different kinds of data to
separate branches).

-- 
				Petr "Pasky" Baudis
The next generation of interesting software will be done
on the Macintosh, not the IBM PC.  -- Bill Gates