summaryrefslogtreecommitdiffstats
path: root/cache-tree.c
diff options
context:
space:
mode:
authorDerrick Stolee <derrickstolee@github.com>2023-03-20 12:26:51 +0100
committerJunio C Hamano <gitster@pobox.com>2023-03-20 20:17:33 +0100
commit2ee11f7261cc7ac386ec683f774472b0309dcc82 (patch)
tree7aa6ffeb54b74efc130b8e4f9d6e4deb0579f0fa /cache-tree.c
parentcommit-graph: simplify compute_generation_numbers() (diff)
downloadgit-2ee11f7261cc7ac386ec683f774472b0309dcc82.tar.xz
git-2ee11f7261cc7ac386ec683f774472b0309dcc82.zip
commit-graph: return generation from memory
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. However, an upcoming change will introduce the ability to set generation values in-memory without writing the commit-graph file. Thus, we can no longer trust 'graph_pos' to indicate whether or not the generation member can be trusted. 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. 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. Signed-off-by: Derrick Stolee <derrickstolee@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'cache-tree.c')
0 files changed, 0 insertions, 0 deletions