On Fri, 2011-07-15 at 16:33 +0100, Long, Martin wrote: > > > > Firstly, I presume the generation number would not form part of the > > SHA1 calculation? No? Cool. > > I suspect this may be where my suggestion falls down. Though I suspect > there is a case for object metadata which doesn't form part of the > SHA. Would generation number tampering be a concern? If you take Jeff's perspective on the purpose of generation numbers (representing metadata about the DAG in a more readily-available format) then "tampering" is not really a concern as the metadata is merely local (to the running instance of Git) ephemera that we can cache between runs for the sake of efficiency. Linus' perspective on generation numbers seems to be of a more hard and fast type of data. So, are we really talking about [corpus] generation numbers (used to describe the state of the DAG in the way one describes his known family tree) or are we talking about _revision_numbers_ (used to describe the commit, as Subversion does)? I think we've got two (or more) groups talking about different things (and aims) and trying to use the same words to do so. > Caching offers the ability to store that metadata, to provide the same > performance gain, but maintain the integrity of the SHA chain. > However, it does still leave the generation number liable to > tampering, meaning a generic non-SHA metadata solution might be > better. I'm not sure where you are going with this. I wouldn't think "tampering" with _current_DAG-based ephemera would do much other than create a performance hit. If you are really talking about a static _revision_number_ then that belongs in the commit, where it cannot be changed (and may be completely meaningless when taken out of context, as SVN revision numbers are). What such a number may entail is probably up for discussion, but perhaps in a different thread. > TBH, there are few situations where historical generations are useful > - finding gen numbers of tags is one of them. Most cases are going to > be for new commits, and in that case, a few new commits at the tip of > each branch will very quickly reduce the number of traversals. What > use case would really create enough traversals that it should be a > performance concern? The answer to this is found in a previous thread http://article.gmane.org/gmane.comp.version-control.git/176807 (remember, generation number vs. revision number...) Also, please don't cull the CC list! (Added Geert Bosch) -- -Drew Northup ________________________________________________ "As opposed to vegetable or mineral error?" -John Pescatore, SANS NewsBites Vol. 12 Num. 59 -- 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