On Wed, Jul 06, 2011 at 01:56:23AM -0500, Jonathan Nieder wrote: > Jeff King wrote: > > > The problem is that existing objects don't have this generation number. > > It's easy to calculate, though, and we could in theory use a notes-cache > > to store it externally. Obviously the complexity and performance aren't > > going to be as good as if it were just in the commit object, but we're > > sadly 6 years too late to make that decision. > > I am still digesting the rest of what you wrote, but wouldn't this be > easy to do today? One could just use a notes-cache while prototyping > and if it seems to work well, introduce new loose and packed object > formats that include a field for the cached generation number. Yes, that's exactly how to do it. I'm just not sure "introduce new loose and packed object formats" is "easy to do". Though I'm not sure we need new formats. It is really just a new header in the commit object. And if we write the code carefully, we should be able to transparently use newly-generated objects with the field, and fall back to a notes-cache (with autogeneration) when it isn't there. Existing git will ignore the new generation field. It does mean that old and new git will generate different sha1s for the exact same commit. I don't know how big a deal this is in practice. It matters a lot more for blobs and trees. But for commits, even if you are replaying a commit, you should be updating the commit timestamp, which is going to give a new sha1. The other thing I worry about is performance. You are building a full notes tree and looking up every commit in the traversal. I don't know how bad that will be (though from my other back-of-the-envelope tests, it may not actually be that bad; notes were designed to be fast for exactly this case). -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html