Re: Handling renames.

From: David Mansfield <david@cobite.com>
Date: Apr 14, 2005, 19:21 UTC
Message-ID: <425EC2D0.2090904@cobite.com>
In-Reply-To: <Pine.LNX.4.58.0504141124220.7211@ppc970.osdl.org>

Linus Torvalds wrote:

Show 9 quoted lines

> 
> On Thu, 14 Apr 2005, Ingo Molnar wrote:
> 
>>there's no redundancy caused by this method: only renames (which are 
>>rare) go through the rename_commit redirection. (to speed up the lookup 
>>the rename_commit object could cache the offset of the two names within 
>>their tree objects.)
> 
>

Show 7 quoted lines

> 
> Some "higher level" thing can add its own rules _on_top_ of git rules. The
> same way we have normal applications having their _own_ rules on top of
> the kernel. You do abstraction in layers, but for this to work, the base 
> you build on top of had better be damn solid, and not have any ugly 
> special cases.
>

Maybe you (or the group) should standardize on a way to 'extend' the commit 'object' in terms of:

the layer1 (git) header for commit object is defined as such-and-such the layer2 (scm or other) header for commit object is defined as such-and-such

Much the way network protocols stack on top of each other. If a standard way of stacking is defined, then it could be much cleaner for future implementors to understand a 'new' stacking protocol, and it will make the scm-level extensions easier to discuss it terms of their own 'layer'.

David