On Wed, Sep 13, 2017 at 2:52 PM, Junio C Hamano <gits...@pobox.com> wrote: > Jonathan Nieder <jrnie...@gmail.com> writes: > >> Treating generation numbers as derived data (as in Jeff King's >> preferred design, if I have understood his replies correctly) would >> also be possible but it does not interact well with shallow clone or >> narrow clone. > > Just like we have skewed committer timestamps, there is no reason to > believe that generation numbers embedded in objects are trustable, > and there is no way for narrow clients to even verify their correctness. > > So I agree with Peff that having generation numbers in object is > pointless; I agree any other derivables like corresponding sha-1 > name is also pointless to have. > > This is a tangent, but it may be fine for a shallow clone to treat > the cut-off points in the history as if they are root commits and > compute generation numbers locally, just like everybody else does. > As generation numbers won't have to be global (because we will not > be embedding them in objects), nobody gets hurt if they do not match > across repositories---just like often-mentioned rename detection > cache, it can be kept as a mere local performance aid and does not > have to participate in the object model.
Locally it helps for some operations such as correct walks. For the network case however, it doesn't really help either. If we had global generation numbers, one could imagine that they are used in the pack negotiation (server advertises the maximum generation number or even gen number per branch; client could binary search in there for the fork point) I wonder if locally generated generation numbers (for the shallow case) could be used somehow to still improve network operations. >> My assumption based on previous conversations (and other external >> conversations like [1]) is that we are going to use SHA2-256 and have >> a pretty strong consensus for that. Don't worry! > > Hmph, I actually re-read the thread recently, and my impression was > that we didn't quite have a consensus but were leaning towards > SHA3-256. > > I do not personally have a strong preference myself and I would say > that anything will do as long as it is with good longevity and > availability. SHA2 family would be a fine choice due to its age on > both counts, being scrutinized longer and having a chance to be > implemented in many places, even though its age itself may have to > be subtracted from the longevity factor. If we'd get the transition somewhat right, the next transition will be easier than the current transition, such that I am not that concerned about longevity. I am rather concerned about the complexity that is added to the code base (whilst accumulating technical debt instead of clearer abstraction layers)
