On Mon, Aug 10, 2020 at 12:42:29PM -0400, Derrick Stolee wrote: > On 8/8/2020 10:53 PM, Abhishek Kumar via GitGitGadget wrote: > > ... > > Hm. So this scenario actually disables generation numbers completely > in the event that anything in the chain disagrees. I think this is > not the right way to approach the situation, as it will significantly > punish users in this state with slow performance. > > The patch I sent [1] is probably better: it uses generation number > v1 if the tip of the chain does not have a GDAT chunk. > > [1] https://lore.kernel.org/git/a3910f82-ab2e-bf35-ac43-c30d77f3c96b@xxxxxxxxx/ > Yes, the patch is an clear improvement over my (convoluted and incorrect) logic. Will add. > > ... > > Please make a point to move the line that checks GIT_TEST_COMMIT_GRAPH_NO_GDAT > from its current location to after this line. We want to make sure that the > environment variable is checked _last_. The best location is likely the start > of the implementation of compute_generation_numbers(), or immediately before > the call to the method. > Sure, will do. > > ... > > It would be valuable to double-check here that the values in the GDAT chunk > are correct. I'm concerned about the possibility that the 'generation' > member of struct commit_graph_data gets filled with topological level during > parsing and then that is written as an offset into the CDAT chunk. > > Perhaps this is best left for a follow-up series that updates the 'verify' > subcommand to check the GDAT chunk. If I can understand it correctly, one of ways to update 'verify' subcommand to check the GDAT chunk as well would to be make use of the flag variable introduced in your patch. We can isolate generation number related checks and run checks once with flag = 1 (checking corrected commit dates) and once with flag = 0 (checking topological levels). This has the unfortunate effect of filling all commits twice, but as we cannot change the commit_graph_data->generation any other way, I see no alternatives without changing how commit_graph_generation() works. Would it make more sense if we add the flag to struct commit_graph instead of making it depend solely on g->chunk_generation_data and set it within parse_commit_graph()? We would be able to control the behavior of fill_commit_graph_info() and we will not need to check g->chunk_generation_data before filling every commit. > > Thanks, > -Stolee > Thanks - Abhishek
