Derrick Stolee <dstolee@xxxxxxxxxxxxx> writes: > +Here is a diagram to visualize the shape of the full commit graph, and > +how different generation numbers relate: > + > + +-----------------------------------------+ > + | GENERATION_NUMBER_INFINITY = 0xFFFFFFFF | > + +-----------------------------------------+ > + | | ^ > + | | | > + | +------+ > + | [gen(A) = gen(B)] > + V > + +-------------------------------------+ > + | 0 < commit->generation < 0x40000000 | > + +-------------------------------------+ > + | | ^ > + | | | > + | +------+ > + | [gen(A) > gen(B)] > + V > + +-------------------------------------+ > + | GENERATION_NUMBER_ZERO = 0 | > + +-------------------------------------+ > + | ^ > + | | > + +------+ > + [gen(A) = gen(B)] It may be just me but all I can read out of the above is that commit->generation may store 0xFFFFFFFF, a value between 0 and 0x40000000, or 0. I cannot quite tell what the notation [gen(A) <cmp> gen(B)] is trying to say. I am guessing "Two generation numbers within the 'valid' range can be compared" is what the second one is trying to say, but it is much less interesting to know that two infinities compare equal than how generation numbers from different classes compare, which cannot be depicted in the above notation, I am afraid. For example, don't we want to say that a commit with INF can never be reached by a commit with a valid generation number, or something like that? > Design Details > -------------- > > @@ -98,17 +141,12 @@ Future Work > - The 'commit-graph' subcommand does not have a "verify" mode that is > necessary for integration with fsck. > > -- The file format includes room for precomputed generation numbers. These > - are not currently computed, so all generation numbers will be marked as > - 0 (or "uncomputed"). A later patch will include this calculation. > - > - After computing and storing generation numbers, we must make graph > walks aware of generation numbers to gain the performance benefits they > enable. This will mostly be accomplished by swapping a commit-date-ordered > priority queue with one ordered by generation number. The following > - operations are important candidates: > + operation is an important candidate: Good.
