On 8/27/2020 2:39 AM, Abhishek Kumar wrote: > Thinking about this, I feel creating a new section called "Handling > Mixed Generation Number Chains" made more sense: > > ## Handling Mixed Generation Number Chains > > With the introduction of generation number v2 and generation data chunk, > the following scenario is possible: > > 1. "New" Git writes a commit-graph with a GDAT chunk. > 2. "Old" Git writes a split commit-graph on top without a GDAT chunk. I like the idea of this section, and this setup is good. > The commits in the lower layer will be interpreted as having very large > generation values (commit date plus offset) compared to the generation > numbers in the top layer (toplogical level). This violates the > expectation that the generation of a parent is strictly smaller than the > generation of a child. In such cases, we revert to using topological > levels for all layers to maintain backwards compatability. s/toplogical/topological But also, we don't want to phrase this as "in this case, we do the wrong thing" but instead A naive approach of using the newest available generation number from each layer would lead to violated expectations: the lower layer would use corrected commit dates which are much larger than the topological levels of the higher layer. For this reason, Git inspects each layer to see if any layer is missing corrected commit dates. In such a case, Git only uses topological levels. > When writing a new layer in split commit-graph, we write a GDAT chunk > only if the topmost layer has a GDAT chunk. This guarantees that if a > lyer has GDAT chunk, all lower layers must have a GDAT chunk as well. s/lyer/layer Perhaps leaving this at a higher level than referencing "GDAT chunk" is advisable. Perhaps use "we write corrected commit dates" or "all lower layers must store corrected commit dates as well", for example. > Rewriting layers follows similar approach: if the topmost layer below > set of layers being rewriteen (in the split commit-graph chain) exists, > and it does not contain GDAT chunk, then the result of rewrite does not > have GDAT chunks either. This could use more positive language to make it clear that sometimes we _do_ want to write corrected commit dates when merging layers: When merging layers, we do not consider whether the merged layers had corrected commit dates. Instead, the new layer will have corrected commit dates if and only if all existing layers below the new layer have corrected commit dates. Thanks, -Stolee
