From patchwork Tue Jul 12 23:10:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Taylor Blau X-Patchwork-Id: 12915792 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D1D41C43334 for ; Tue, 12 Jul 2022 23:10:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233227AbiGLXKe (ORCPT ); Tue, 12 Jul 2022 19:10:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229514AbiGLXKb (ORCPT ); Tue, 12 Jul 2022 19:10:31 -0400 Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 799EC9B1A9 for ; Tue, 12 Jul 2022 16:10:30 -0700 (PDT) Received: by mail-qv1-xf2b.google.com with SMTP id l2so3673683qvt.2 for ; Tue, 12 Jul 2022 16:10:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ttaylorr-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=nYNZgAuTiOavJ/JkYhkf8y8k5mtvvNKydg1YsBBm4zc=; b=PL41dNT6JLV/c/PgGGeoyX/HbQxvcdK2c+gLPURKP3Uig+IWwy9HSusr4ZjTc3OL5x o6oGFLc4SymiFhFSfQeEEhEy+whtc5iU5R5mlxfcd+ZKNeEGMA0RhDclioD+jfkZCCZb T05WnVfAUPfuUDzpxct+Ajcr737B1zWuODnVTCHgJHQm4yYOGeeWHqqLYjCeMnJ4l0np vesEwc2tYFl0NKbV2ez6GlQr1RabR22dqqwBTmoV/3RB9gnAC7BLFlbPmhi1YqBMAkhM 5hIxWA0j/V18P3+Hh6iKekqLMMXzWX6ygPYvzxv7XsZAge1ZUMKi7kLBtDXm/lNxUSWN kjIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=nYNZgAuTiOavJ/JkYhkf8y8k5mtvvNKydg1YsBBm4zc=; b=re03D2U1ZuzTd3qMNqnoDyOSlXOaCAPFkw/Ic+jB3XVNrg3pfBq8xrfEUZkvpZ9VHN RA86+SjAP5J33FYn8QewMf/y3QsnWZtGh16A1asad5T5iQpHqRd8IpfwUu+OQ7VwoUDg SV/uMAOg2e2tSkWBhV6FCrMS2u7szqf1p9I3aMQAU31E2UO+CK9dxnL3YsW/GRROqvwF kKbuv5olUtiTDtr4Dx27DVsfxL6uzs+CWmmqvHOKsLxeP4dRqGg/L87m2GOpj/SRH9Zd QrKKh2RrJ1blSf7nDpcymWJkUK3YJDV483lQBZzZC4Dve6Q2k6QjxLZMSAGM64LyghhR T0BA== X-Gm-Message-State: AJIora+Gum2yxdrg2Fu3laQEl97bItQ5Xzm8MXDGKeyi8/qBCxA/Yx2b nq1ZfFzfGSJowV7Cjx0Mn5Bd7rfHGcfcjg== X-Google-Smtp-Source: AGRyM1tbUYaD3CRhRQAzbjun4gSomXP3vr6tStaabyF6EE6WXhHfr3vycJm3elnGZ8pHwv2uUDBmWQ== X-Received: by 2002:a05:6214:2302:b0:470:2d10:b6e4 with SMTP id gc2-20020a056214230200b004702d10b6e4mr656074qvb.72.1657667429493; Tue, 12 Jul 2022 16:10:29 -0700 (PDT) Received: from localhost (104-178-186-189.lightspeed.milwwi.sbcglobal.net. [104.178.186.189]) by smtp.gmail.com with ESMTPSA id m3-20020a05620a24c300b006b53fe19c41sm10798902qkn.14.2022.07.12.16.10.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 16:10:29 -0700 (PDT) Date: Tue, 12 Jul 2022 19:10:28 -0400 From: Taylor Blau To: git@vger.kernel.org Cc: gitster@pobox.com, derrickstolee@github.com, peff@peff.net, ps@pks.im, wfc@wfchandler.org Subject: [PATCH 1/3] t5318: demonstrate commit-graph generation v2 corruption Message-ID: <0a49c86037bac200bb23e1abf9f67363e99c4b7c.1657667404.git.me@ttaylorr.com> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org When upgrading a commit-graph using generation v1 to one using generation v2, it is possible to force Git into a corrupt state where it (incorrectly) believes that a GDO2 chunk is necessary, *after* deciding not to write one. This makes subsequent reads using the commit-graph produce the following error message: fatal: commit-graph requires overflow generation data but has none Demonstrate this bug by increasing our test coverage to include a minimal example of upgrading a commit-graph from generation v1 to v2. The only notable components of this test are: - The committer date of the commit is chosen carefully so that the offset underflows when computed using a v1 generation number, but would not overflow when using v2 generation numbers. - The upgrade to generation number v2 must read in the v1 generation numbers, which we can do by passing `--changed-paths`, which will force the commit-graph internals to call `fill_commit_graph_info()`. A future patch will squash this bug. Reported-by: Jeff King Reproduced-by: Will Chandler Signed-off-by: Taylor Blau --- t/t5318-commit-graph.sh | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh index fbf0d64578..4d9f62f22d 100755 --- a/t/t5318-commit-graph.sh +++ b/t/t5318-commit-graph.sh @@ -811,4 +811,31 @@ test_expect_success 'set up and verify repo with generation data overflow chunk' graph_git_behavior 'generation data overflow chunk repo' repo left right +test_expect_failure 'overflow during generation version upgrade' ' + git init overflow-v2-upgrade && + ( + cd overflow-v2-upgrade && + + # This commit will have a date at two seconds past the Epoch, + # and a (v1) generation number of 1, since it is a root commit. + # + # The offset will then be computed as 2-1, which will underflow + # to 2^31, which is greater than the v2 offset small limit of + # 2^31-1. + # + # This is sufficient to need a large offset table for the v2 + # generation numbers. + test_commit --date "@2 +0000" base && + git repack -d && + + # Test that upgrading from generation v1 to v2 correctly + # produces the overflow table. + git -c commitGraph.generationVersion=1 commit-graph write && + git -c commitGraph.generationVersion=2 commit-graph write \ + --changed-paths && + + git rev-list --all + ) +' + test_done From patchwork Tue Jul 12 23:10:31 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Taylor Blau X-Patchwork-Id: 12915793 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77919C43334 for ; Tue, 12 Jul 2022 23:10:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233845AbiGLXKl (ORCPT ); Tue, 12 Jul 2022 19:10:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233195AbiGLXKe (ORCPT ); Tue, 12 Jul 2022 19:10:34 -0400 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 12BDD9B9C7 for ; Tue, 12 Jul 2022 16:10:33 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id q13so2335103qkc.9 for ; Tue, 12 Jul 2022 16:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ttaylorr-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=xQDAKvb0FE2cG0PUsInWPKPYo/rQ4AnDRWkJClFki68=; b=DVxnpv1PavN9R33Sx8OOGcWH/jNSDeA4j/aLD612g8di+DK/04+j2X5Qvm2on9eLHo K8WgpUzyQDmLmb2YGaQT7xFNpxWcUX4Q4JAt8TS4Ici5xpZxh/O2wLx07H7/MJRVCV+n nTt5XlYIIAauYfMG3tIAa4MNTG/iiahP0gYJFd5Rwmq8gKuBBC2Tzw3rHnCgQuCyg3YU dUDLWUkgIGK60V8+Kd0qusOmXCNwq8nTKgbUY1ssPQrT0iVlyPwU7mLTFeQdwojODAuh qyr5ssAkamwuPncQcXzvQVbWUZDyteFr/eNRT5jDx3BTL8SPDcciZPXo5lWNJx+N6Bws JhoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xQDAKvb0FE2cG0PUsInWPKPYo/rQ4AnDRWkJClFki68=; b=1zAd96stNl4gYoV7x8UitHxFsVIGC2DantjthKOhU0CidkOEQoGUm1D5bi1qDIvKF9 n5HZopai2yLKi0x1BU8x7Xo30cxClhCHZczjexLWfWPaq83VfzzL/fxTumJvyPyUDtoS cFB1WL4eLMjIyekkpHWnt6YLhEG+IAEqP9whkqHHij1IpGaESG3Em88b/gNHa/1bfaoM b89OyQsAKWJ/oHE8RNOdBZkzMdmZjLa6/Y55d9gwhxdkyds1cGQe5vuC2hiKxJ44PSLN dHxwv6cHX99wLcxbJPYyEune3sryq/XZsjJEeEq2g70yJoTo7JjIzihxZtTwf2CWLF0v JjCg== X-Gm-Message-State: AJIora/L47ZMsjW1TnumGRPsTEUyEdMY/IpJPxpBErxYuIRCqdV7m1KO 6eWj7HUnPBkqoiPM4dkQKRACuahzF5QYdg== X-Google-Smtp-Source: AGRyM1tG0zC+wrmxwNoXRn68/TRmniLcHXa6QqeZ1M6LKbCp5OrcNOH9BQOaERD/DKfqiJf0qgcp4Q== X-Received: by 2002:a05:620a:210f:b0:6b5:9575:9084 with SMTP id l15-20020a05620a210f00b006b595759084mr514266qkl.587.1657667432028; Tue, 12 Jul 2022 16:10:32 -0700 (PDT) Received: from localhost (104-178-186-189.lightspeed.milwwi.sbcglobal.net. [104.178.186.189]) by smtp.gmail.com with ESMTPSA id c7-20020ac87dc7000000b003172da668desm8692370qte.50.2022.07.12.16.10.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 16:10:31 -0700 (PDT) Date: Tue, 12 Jul 2022 19:10:31 -0400 From: Taylor Blau To: git@vger.kernel.org Cc: gitster@pobox.com, derrickstolee@github.com, peff@peff.net, ps@pks.im, wfc@wfchandler.org Subject: [PATCH 2/3] commit-graph: introduce `repo_find_commit_pos_in_graph()` Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Low-level callers in systems that are adjacent to the commit-graph (like the changed-path Bloom filter code) could benefit from being able to call a function like `parse_commit_in_graph()` without modifying the corresponding commit slab data. This is useful in contexts where that slab data is being used to prepare for an upcoming commit-graph write, where Git must be careful to avoid clobbering any of that data during a read operation. Introduce a low-level variant of `parse_commit_in_graph()` which returns the graph position of a given commit only, without modifying any of the slab data. Signed-off-by: Taylor Blau --- commit-graph.c | 12 +++++++++--- commit-graph.h | 15 +++++++++++++++ 2 files changed, 24 insertions(+), 3 deletions(-) diff --git a/commit-graph.c b/commit-graph.c index 92d4503336..1c34ae1ea4 100644 --- a/commit-graph.c +++ b/commit-graph.c @@ -889,6 +889,14 @@ static int find_commit_pos_in_graph(struct commit *item, struct commit_graph *g, } } +int repo_find_commit_pos_in_graph(struct repository *r, struct commit *c, + uint32_t *pos) +{ + if (!prepare_commit_graph(r)) + return 0; + return find_commit_pos_in_graph(c, r->objects->commit_graph, pos); +} + struct commit *lookup_commit_in_graph(struct repository *repo, const struct object_id *id) { struct commit *commit; @@ -946,9 +954,7 @@ int parse_commit_in_graph(struct repository *r, struct commit *item) void load_commit_graph_info(struct repository *r, struct commit *item) { uint32_t pos; - if (!prepare_commit_graph(r)) - return; - if (find_commit_pos_in_graph(item, r->objects->commit_graph, &pos)) + if (repo_find_commit_pos_in_graph(r, item, &pos)) fill_commit_graph_info(item, r->objects->commit_graph, pos); } diff --git a/commit-graph.h b/commit-graph.h index 2e3ac35237..f23b9e9026 100644 --- a/commit-graph.h +++ b/commit-graph.h @@ -40,6 +40,21 @@ int open_commit_graph(const char *graph_file, int *fd, struct stat *st); */ int parse_commit_in_graph(struct repository *r, struct commit *item); +/* + * Fills `*pos` with the graph position of `c`, and returns 1 if `c` is + * found in the commit-graph belonging to `r`, or 0 otherwise. + * Initializes the commit-graph belonging to `r` if it hasn't been + * already. + * + * Note: this is a low-level helper that does not alter any slab data + * associated with `c`. Useful in circumstances where the slab data is + * already being modified (e.g., writing the commit-graph itself). + * + * In most cases, callers should use `parse_commit_in_graph()` instead. + */ +int repo_find_commit_pos_in_graph(struct repository *r, struct commit *c, + uint32_t *pos); + /* * Look up the given commit ID in the commit-graph. This will only return a * commit if the ID exists both in the graph and in the object database such From patchwork Tue Jul 12 23:10:33 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Taylor Blau X-Patchwork-Id: 12915794 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8199DC43334 for ; Tue, 12 Jul 2022 23:10:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233610AbiGLXKp (ORCPT ); Tue, 12 Jul 2022 19:10:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233517AbiGLXKh (ORCPT ); Tue, 12 Jul 2022 19:10:37 -0400 Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A71D5B5D12 for ; Tue, 12 Jul 2022 16:10:35 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id a21so9437455qtw.10 for ; Tue, 12 Jul 2022 16:10:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ttaylorr-com.20210112.gappssmtp.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6Gz853oxrMnlo9IcFjLnfmzhl+L3KoJMt4plt5FBr5I=; b=tM8f+OKekSwexIYwqXAAHnbUNLQU40IkYPWNuVNsgJrrjziBcVL1WyR1n3dHt+c9ko H2yZj9zpb+Qf6ea/Nvg/qOpij3zgeHN/4ry70DXHOtpnTEqBvYbWF785c1txngUbWAh1 eXO47C5YJ7klNFhc+UF2Gef2T1QeQh+XRw3qVLhhe51Hpf8nIbo5nlqhw1esTcqWUE6x JJhGG0yYKmXA9rdeuQ7miDdvZa+mN68zxjxR/J0WnNpeFSBpQKWOimn5K6lgUnuFUMxY Vvdutuf+Z7uPPeARtZRDupX67+UL8he7yvjN3LdQdz7LT1zrYDfLteZJk1ou0/0xWK3m USQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6Gz853oxrMnlo9IcFjLnfmzhl+L3KoJMt4plt5FBr5I=; b=d9pvNN9Z4UDiojqsRrNG4930k6q9idlRGKlpai+rBMacwkND1GErYRfZl9MuWAdH88 txXGpOaZAO0qceFpsLk6VPE95enbBxzhau2luvAMyyxg2MZaJYwykQXoyhCkSwkebnsy m/VqIv6zFstv591t+TdBrjWiAqNSK18Gth+c7ZTtKIZfmA8kOVAlNrNwRpDSUbWNwzZR iJjgQywHdkJjqK3jsYJAZnjF1eN2PotrI2rRJrxebbXDimWvjKM2hZEsQsXujZSe7QpR 6Hb1T4zew0QkHoHXuM+HHFRVH3o6k4iCcpTjKGSvmAsUjCflozSfUQK9x18tFkHPrcKA 2tsw== X-Gm-Message-State: AJIora+YSJA6wyHz04GkZSsCd3UQ4WHZ0LkHB87ZzyUB8S79QolgX5a4 OIfX173jhnoaxKyvCM7X4cLF9RJISriQLw== X-Google-Smtp-Source: AGRyM1vdrijecwgK0+pkMbpi0h9+8TmCRDWupZVCeGuoeq1bSm3i1lXimmwaYgPy0/YIE0eMo32T9A== X-Received: by 2002:a05:622a:1453:b0:31d:4c06:4a04 with SMTP id v19-20020a05622a145300b0031d4c064a04mr385218qtx.432.1657667434604; Tue, 12 Jul 2022 16:10:34 -0700 (PDT) Received: from localhost (104-178-186-189.lightspeed.milwwi.sbcglobal.net. [104.178.186.189]) by smtp.gmail.com with ESMTPSA id y13-20020a05620a44cd00b006b5a9e53105sm2139390qkp.91.2022.07.12.16.10.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Jul 2022 16:10:34 -0700 (PDT) Date: Tue, 12 Jul 2022 19:10:33 -0400 From: Taylor Blau To: git@vger.kernel.org Cc: gitster@pobox.com, derrickstolee@github.com, peff@peff.net, ps@pks.im, wfc@wfchandler.org Subject: [PATCH 3/3] commit-graph: fix corrupt upgrade from generation v1 to v2 Message-ID: References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org The previous commit demonstrates a bug where a commit-graph using generation v2 could enter a state where one of the GDA2 values has its most-significant bit set (indicating that its value should be read from the extended offset table in the GDO2 chunk) without having a GDO2 chunk to read from. This results in the following error message being displayed to the caller: fatal: commit-graph requires overflow generation data but has none This bug arises in the following scenario: - We decide to write a commit-graph using generation number v2, and decide (correctly) that no GDO2 chunk is necessary (e.g., because all of the commiter date offsets are no larger than 2^31-1). - The v2 generation numbers are stored in the `->generation` member of the commit slab holding `struct commit_graph_data`'s. - Later on, `load_commit_graph_info()` is called, overwriting the v2 generation data in the aforementioned slab with any existing v1 generation data. Then, when the commit-graph code goes to write the GDA2 chunk via `write_graph_chunk_generation_data()`, we use the overwritten generation v1 data in a place where we expect to use a v2 generation number: offset = commit_graph_data_at(c)->generation - c->date; ...because `commit_graph_data_at(c)->generation` used to hold the v2 generation data, but it was overwritten to contain the v1 generation number via `load_commit_graph_info()`. If the `offset` computation above overflows the v2 generation number max, then `write_graph_chunk_generation_data()` will update its count of large offsets and write the marker accordingly: if (offset > GENERATION_NUMBER_V2_OFFSET_MAX) { offset = CORRECTED_COMMIT_DATE_OFFSET_OVERFLOW | num_generation_data_overflows; num_generation_data_overflows++; } and reads will look for the GDO2 chunk containing the overflowing v2 generation number, *after* the commit-graph code decided that no such chunk was necessary. The main problem is that the slab containing `struct commit_graph_data` has a dual purpose. It is used to hold data that we are about to write to disk while generating a commit-graph, as well as hold data that was read from an existing commit-graph. When the two mix, namely when the result of reading the commit-graph has a side-effect that mixes poorly with an in-progress commit-graph write, we end up with corrupt data. A complete fix might be to introduce a new slab that is used exclusively for writing, and gate access between the two slabs based on context provided by the caller (e.g., whether this computation is part of a "read" or "write" operation). But a more minimal fix addresses the only known path which overwrites the slab data, which is `compute_bloom_filters()` -> `get_or_compute_bloom_filter()` -> `load_commit_graph_info()` -> `fill_commit_graph_info()` by avoiding the last call which clobbers the data altogether. This path only needs to learn the graph position of a given commit so that it can be used in `load_bloom_filter_from_graph()`. By replacing the last steps of the above with one that records the graph position into a temporary variable which is then used to load the existing Bloom data, we eliminate the clobbering, removing the corruption. Signed-off-by: Taylor Blau --- bloom.c | 10 +++++----- t/t5318-commit-graph.sh | 2 +- 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/bloom.c b/bloom.c index 5e297038bb..816f063dca 100644 --- a/bloom.c +++ b/bloom.c @@ -30,10 +30,9 @@ static inline unsigned char get_bitmask(uint32_t pos) static int load_bloom_filter_from_graph(struct commit_graph *g, struct bloom_filter *filter, - struct commit *c) + uint32_t graph_pos) { uint32_t lex_pos, start_index, end_index; - uint32_t graph_pos = commit_graph_position(c); while (graph_pos < g->num_commits_in_base) g = g->base_graph; @@ -203,9 +202,10 @@ struct bloom_filter *get_or_compute_bloom_filter(struct repository *r, filter = bloom_filter_slab_at(&bloom_filters, c); if (!filter->data) { - load_commit_graph_info(r, c); - if (commit_graph_position(c) != COMMIT_NOT_FROM_GRAPH) - load_bloom_filter_from_graph(r->objects->commit_graph, filter, c); + uint32_t graph_pos; + if (repo_find_commit_pos_in_graph(r, c, &graph_pos)) + load_bloom_filter_from_graph(r->objects->commit_graph, + filter, graph_pos); } if (filter->data && filter->len) diff --git a/t/t5318-commit-graph.sh b/t/t5318-commit-graph.sh index 4d9f62f22d..f5f0895631 100755 --- a/t/t5318-commit-graph.sh +++ b/t/t5318-commit-graph.sh @@ -811,7 +811,7 @@ test_expect_success 'set up and verify repo with generation data overflow chunk' graph_git_behavior 'generation data overflow chunk repo' repo left right -test_expect_failure 'overflow during generation version upgrade' ' +test_expect_success 'overflow during generation version upgrade' ' git init overflow-v2-upgrade && ( cd overflow-v2-upgrade &&