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.)
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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
