On Tue, Oct 30 2018, Junio C Hamano wrote: > Derrick Stolee <stolee@xxxxxxxxx> writes: >> In contrast, maximum generation numbers and corrected commit >> dates both performed quite well. They are frequently the top >> two performing indexes, and rarely significantly different. >> >> The trade-off here now seems to be: which _property_ is more important, >> locally-computable or backwards-compatible? > > Nice summary. > > As I already said, I personally do not think being compatible with > currently deployed clients is important at all (primarily because I > still consider the whole thing experimental), and there is a clear > way forward once we correct the mistake of not having a version > number in the file format that tells the updated clients to ignore > the generation numbers. For longer term viability, we should pick > something that is immutable, reproducible, computable with minimum > input---all of which would lead to being incrementally computable, I > would think. I think it depends on what we mean by backwards compatibility. None of our docs are saying this is experimental right now, just that it's opt-in like so many other git-config(1) options. So if we mean breaking backwards compatibility in that we'll write a new file or clobber the existing one with a version older clients can't use as an optimization, fine. But it would be bad to produce a hard error on older clients, but avoiding that seems as easy as just creating a "commit-graph2" file in .git/objects/info/.
