Message ID | abd3e7a67beb80ef687253ddb8bb5fe7a769357f.1678902343.git.gitgitgadget@gmail.com (mailing list archive) |
---|---|
State | Accepted |
Commit | 2ee11f7261cc7ac386ec683f774472b0309dcc82 |
Headers | show |
Series | ref-filter: ahead/behind counting, faster --merged option | expand |
"Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Derrick Stolee <derrickstolee@github.com> > > The commit_graph_generation() method used to report a value of > GENERATION_NUMBER_INFINITY if the commit_graph_data_slab had an instance > for the given commit but the graph_pos indicated the commit was not in > the commit-graph file. > > Instead, trust the 'generation' member if the commit has a value in the > slab _and_ the 'generation' member is non-zero. Otherwise, treat it as > GENERATION_NUMBER_INFINITY. I would replace "Instead" with "However, a future commit intends to compute and use commit generation numbers even for commits that are not in the commit-graph file (and thus have no graph_pos). Therefore, we need a new criterion for deciding if a generation number can be trusted:" (or something to that effect). > This only makes a difference for a very old case for the commit-graph: > the very first Git release to write commit-graph files wrote zeroes in > the topological level positions. If we are parsing a commit-graph with > all zeroes, those commits will now appear to have > GENERATION_NUMBER_INFINITY (as if they were not parsed from the > commit-graph). > > I attempted several variations to work around the need for providing an > uninitialized 'generation' member, but this was the best one I found. It > does require a change to a verification test in t5318 because it reports > a different error than the one about non-zero generation numbers. Thanks for investigating, and I think the method in this patch would work. As you have stated, this only affects the commit-graph files that once upon a time were written with no generation numbers, and this patch makes those behave as if there were no generation numbers in the first place (which is exactly what happened).
diff --git a/commit-graph.c b/commit-graph.c index deccf984a0d..b4da4e05067 100644 --- a/commit-graph.c +++ b/commit-graph.c @@ -116,12 +116,10 @@ timestamp_t commit_graph_generation(const struct commit *c) struct commit_graph_data *data = commit_graph_data_slab_peek(&commit_graph_data_slab, c); - if (!data) - return GENERATION_NUMBER_INFINITY; - else if (data->graph_pos == COMMIT_NOT_FROM_GRAPH) - return GENERATION_NUMBER_INFINITY; + if (data && data->generation) + return data->generation; - return data->generation; + return GENERATION_NUMBER_INFINITY; } static struct commit_graph_data *commit_graph_data_at(const struct commit *c) diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh index 049c5fc8ead..b6e12115786 100755 --- a/t/t5318-commit-graph.sh +++ b/t/t5318-commit-graph.sh @@ -630,7 +630,7 @@ test_expect_success 'detect incorrect generation number' ' test_expect_success 'detect incorrect generation number' ' corrupt_graph_and_verify $GRAPH_BYTE_COMMIT_GENERATION "\01" \ - "non-zero generation number" + "commit-graph generation for commit" ' test_expect_success 'detect incorrect commit date' '