From: Taylor Blau <ttaylorr@openai.com>
To: Peter Elmers <peter.elmers@databricks.com>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [BUG] git bundle create with bitmaps omits tree required by advertised ref
Date: Tue, 8 Sep 2026 17:33:19 -0500 [thread overview]
Message-ID: <aqCNL8y9wLLP4ovm@com-79390> (raw)
In-Reply-To: <CALY5j-0K-LfowAavH8X3UfZ24eAsoX=xew=KTt=4uCfZrdwXQw@mail.gmail.com>
On Tue, Sep 08, 2026 at 10:23:37AM +0200, Peter Elmers wrote:
> What did you do before the bug happened? (Steps to reproduce your issue)
>
> I created two sibling commits with the same root tree, stored one at a local
> branch and the other at a remote-tracking ref, wrote a pack bitmap, and created
> a bundle that included the local branch while excluding the remote-tracking
> ref.
>
> Adding `-c pack.useBitmaps=false` appears to fix the issue.
>
> The following script reproduces the issue:
Interesting. I reproduced what you wrote here using your script. I
highly suspect what's going on here is that the non-bitmap case
overcounts some objects beyond the boundary whereas the bitmap case
builds an exact answer.
The non-bitmap traversal only marked boundary trees UNINTERESTING in
this case, so it happened to keep the shared tree.
We can fix this with something like the following (only lightly tested)
patch, but it has some test fallout for cases where we generate bundles
with only tags (+CC Peff who may have some opinions).
--- 8< ---
Subject: [PATCH] bundle: restrict pack haves to recorded prerequisites
`write_pack_data()` uses every UNINTERESTING tip as a pack have, but the
bundle header records only boundary commits. If an included commit
shares a tree with an excluded sibling, a bitmap walk can omit that tree
while the header requires only their parent. A recipient with the parent
can verify and unbundle the result while lacking the advertised
commit's tree.
Restrict pack haves to UNINTERESTING commits marked BOUNDARY, which
are recorded as prerequisites. Other excluded tips must not suppress
objects that the advertised refs need.
As a consequence, there is a bit of test fallout in t6020.13. That test
includes the tags while excluding all branch tips. Its header records
no prerequisites, but its pack previously contained only the three
tag objects: the excluded tips caused their target histories to be
omitted.
But that bundle was already incomplete! With no prerequisites, it must
provide the history reachable from its advertised tags. Restricting
pack haves to recorded prerequisites includes that history, increasing
the expected object count as below.
Reported-by: Peter Elmers <peter.elmers@databricks.com>
Signed-off-by: Taylor Blau <ttaylorr@openai.com>
---
bundle.c | 7 +++++--
t/t6020-bundle-misc.sh | 14 ++++++++++++--
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/bundle.c b/bundle.c
index f55a521b2a1..06a52b8e705 100644
--- a/bundle.c
+++ b/bundle.c
@@ -359,10 +359,13 @@ static int write_pack_data(int bundle_fd, struct rev_info *revs, int progress)
for (i = 0; i < revs->pending.nr; i++) {
struct object *object = revs->pending.objects[i].item;
- if (object->flags & UNINTERESTING)
+ if (object->flags & UNINTERESTING) {
+ if (!(object->flags & BOUNDARY))
+ continue; /* Not a bundle prerequisite. */
oid_array_append(&opts.haves, &object->oid);
- else
+ } else {
oid_array_append(&opts.wants, &object->oid);
+ }
}
if (odb_generate_pack(revs->repo->objects, &generator, &opts)) {
diff --git a/t/t6020-bundle-misc.sh b/t/t6020-bundle-misc.sh
index 939d4214f4d..6fce6252a11 100755
--- a/t/t6020-bundle-misc.sh
+++ b/t/t6020-bundle-misc.sh
@@ -446,8 +446,9 @@ test_expect_success 'create bundle 4 - with tags' '
make_user_friendly_and_stable_output >actual &&
test_cmp expect actual &&
- test_bundle_object_count 4.bdl 3 &&
- test_bundle_object_count stdin-4.bdl 3
+ # With no prerequisites, include the tag targets and their history.
+ test_bundle_object_count 4.bdl 40 &&
+ test_bundle_object_count stdin-4.bdl 40
'
test_expect_success 'clone from bundle' '
@@ -784,4 +785,13 @@ do
'
done
+test_expect_success 'bundle with bitmaps includes trees shared with an excluded sibling' '
+ commit=$(git commit-tree main^{tree} -p main^ -m rewritten) &&
+ git branch rewritten "$commit" &&
+ test_when_finished "git branch -D rewritten" &&
+ git repack -adb &&
+ git -c pack.useBitmaps=true bundle create bitmap.bdl main..rewritten &&
+ test_bundle_object_count bitmap.bdl 3
+'
+
test_done
base-commit: b8242b093d9e941a34460d715e3ce616a34ac3fe
--
2.55.0.openai.744.g47c847ce2641
prev parent reply other threads:[~2026-09-08 22:33 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 8:23 [BUG] git bundle create with bitmaps omits tree required by advertised ref Peter Elmers
2026-09-08 22:33 ` Taylor Blau [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aqCNL8y9wLLP4ovm@com-79390 \
--to=ttaylorr@openai.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=peter.elmers@databricks.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox