From: Derrick Stolee Date: Thu, 12 Apr 2018 11:35:36 GMT Subject: Re: [PATCH v2 07/10] commit-graph.txt: update future work Message-ID: In-Reply-To: On 4/12/2018 5:12 AM, Junio C Hamano wrote: > Derrick Stolee 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) > 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? My intention with the arrows was to demonstrate where parent relationships can go, and the generation-number relation between a commit A with parent B. Clearly, this diagram is less than helpful. > >> 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.