On Mon, 17 Aug 2020 at 03:32, Taylor Blau <me@xxxxxxxxxxxx> wrote: > On Mon, Aug 17, 2020 at 02:16:08AM +0200, Jakub Narębski wrote: > > "Abhishek Kumar via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > > > > We will introduce an additional commit-graph chunk, Generation Data chunk, > > > and store corrected commit date offsets in GDAT chunk while storing > > > topological levels in CDAT chunk. The old versions of Git would ignore GDAT > > > chunk, using topological levels from CDAT chunk. In contrast, new versions > > > of Git would use corrected commit dates, falling back to topological level > > > if the generation data chunk is absent in the commit-graph file. > > > > All right. > > > > However I think the cover letter should also describe what should happen > > in a mixed version environment (for example new Git on command line, > > copy of old Git used by GUI client), and in particular what should > > happen in a mixed-chain case - both for reading and for writing the > > commit-graph file. > > > > For *writing*: because old Git would create commit-graph layers without > > the GDAT chunk, to simplify the behavior and make easy to reason about > > commit-graph data (the situation should be not that common, and > > transient -- it should get more rare as the time goes), we want the > > following behavior from new Git: > > > > - If top layer contains the GDAT chunk, or we are rewriting commit-graph > > file (--split=replace), or we are merging layers and there are no > > layers without GDAT chunk below set of layers that are merged, then > > > > write commit-graph file or commit-graph layer with GDAT chunk, > > > > otherwise > > > > write commit-graph layer without GDAT chunk. > > > > This means that there are commit-graph layers without GDAT chunk if > > and only if the top layer is also without GDAT chunk. > > This seems very sane to me, and I'd be glad to see it spelled out in > more specific detail. I was wondering this myself, and had to double > check with Stolee off-list that my interpretation of Abhishek's code was > correct. > > But yes, only writing GDAT chunks when all layers in the chain have GDAT > chunks makes sense, since we can't interoperate between corrected dates > and topological levels. Since we can't fill in the GDAT data of layers > generated in pre-GDAT versions of Git without invalidating the GDAT > layers on-disk, there's no point to speculatively computing both chunks. > > Merging rules are obviously correct, which is good. For what it's worth, > the '--split=replace' case is what we'll really care about at GitHub, > since it's unlikely we'd drop all existing commit-graph chains and > rebuild them from scratch. More likely is that we'll let the new GDAT > chunks trickle in over time when we run 'git commit-graph write' with > '--split=replace', which happens "every so often". To be more detailed, without '--split=replace' we would want the following layer merging behavior: [layer with GDAT][with GDAT][without GDAT][without GDAT][without GDAT] In the split commit-graph chain above, merging two topmost layers should create a layer without GDAT; merging three topmost layers (and any other layers, e.g. two middle ones) should create a layer with GDAT. > > For *reading* we want to use generation number v2 (corrected commit > > date) if possible, and fall back to generation number v1 (topological > > levels). > > > > - If the top layer contains the GDAT chunk (or maybe even if the topmost > > layer that involves all commits in question, not necessarily the top > > layer in the full commit-graph chain), then use generation number v2 > > I don't follow this. If we have a multi-layer chain, either all or none > of the layers have a GDAT chunk. So, "if the top layer contains the GDAT > chunk" makes sense, since it implies that all layers have the GDAT > chunk. I don't see how "even if the topmost layer that involves all > commits in question" would be possible, since (if I'm understanding your > description correctly), we can't have *some* of the layers having a GDAT > chunk with others only having a CDAT chunk. > > I'm a little confused here. This is only speculative, and most probably totally unnecessary complication (either that, or something that we would get for free). Assume that the command in question operates only on historical data; for example `git log --topo-order HEAD~1000`. If all commits (or, what's equivalent, most recent commits i.e. HEAD~1000) have their data in split commit-graph layers with GDAT, we can theoretically use generation number v2, even if there are some newer commits that have their data in layers without GDAT (and some even newer ones outside commit-graph files). I hope that this explains my (possibly harebrained) idea. > > - commit_graph_data->generation stores corrected commit date, > > computed as sum of committer date (from CDAT) and offset (from GDAT) > > > > - A can reach B => gen(A) < gen(B) > > > > - there is no need for committer date heuristics, and no need for > > limiting use of generation number to where there is a cutoff (to not > > hamper performance). > > > > - If there are layers without GDAT chunks, which thanks to the write > > behavior means simply top layer without GDAT chunk, we need to turn > > off use of generation numbers or fall back to using topological levels > > Good, I'm glad that this can be a quick check (that we can cache for > future reads, but I'm not even sure the caching would be necessary > without measuring). There is a question where to store the information that we cannot use generation number v2 (that 'generation' contains topological levels and not corrected commit date): - create new global variable - store it in `struct split_commit_graph_opts` - set `chunk_generation_data` to NULL for all graphs in chain (it is in `struct commit_graph`)? > > > > - commit_graph_data->generation stores topological levels, > > taken from CDAT chunk (30-bits) > > > > - A can reach B => gen(A) < gen(B) > > > > - we probably want to keep tie-breaking of sorting by generation > > number via committer date, and limit use of generation number as > > opposed to using committer date heuristics (with slop) to not make > > performance worse. > > All makes very good sense, except for the one point I raised above. > > > > > > > Thanks to Dr. Stolee, Dr. Narębski, and Taylor for their reviews on the > > > first version. > > Thanks, Abhishek for your great work on this. I was feeling bad that I > wasn't more involved in the early discussions about the transition plan, > but what you, Stolee, and Jakub came up with all seems like what I would > have suggested, anyway ;-). Thank you for your work on improving this feature. Best, -- Jakub Narebski
