> The thing I hate about it is very fundamental: I think it's a hack around a basic git > design mistake. And it's a mistake we have known about for a long time. > > Now, I don't think it's a *fatal* mistake, but I do find it very broken to basically > say "we made a mistake in the original commit design, and instead of fixing it we > create a separate workaround for it". > > THAT I find distasteful. My reaction is that if we're going to add generation > numbers, then were should just do it the way we should have done them originally, > rather than as some separate hack. There are a few design mistakes in git. The way the object type and size are prefixed to the data for hasing purposes, which prevents aligned fetching from memory-mapped data in the hashing code, isn't too pretty either. But git has generally preferred to avoid storing information that can be recomputed. File renames are the big example. given this, why the heck store generation numbers? They *can* be computed on demand, so arguably they *should*. Cacheing is then an optimization, just like packs, pack indexes, the hashed object storage directories, and all that. I'm in the "make it a cache" camp, honestly. For example, here's a different possible generation number scheme. By making the generation number a cache, it becomes a valid alternative to experiment with. Simply store a topologically sorted list of commits. Each commit's position can serve as a generation number, and is greater than the positions of all ancestors. But by using the offset within the list, the number is stored implicitly. Generation numbers don't have to be consecutive as long as they're correctly ordered, so you could, e.g. choose to make them unique. I don't think this is actually worth it; I'm just using it as a not-completely-insane example of a different design that nonetheless achieves the same goal. Why freeze this in the object format? -- 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