summaryrefslogtreecommitdiffstats
path: root/contrib/persistent-https
diff options
context:
space:
mode:
authorPatrick Steinhardt <ps@pks.im>2026-02-19 08:57:50 +0100
committerJunio C Hamano <gitster@pobox.com>2026-02-19 10:41:18 -0800
commit7174098834e30d2da1834bbfd0aaf575f6d6bb1a (patch)
tree6f9edde73c1d1caaa7804d4f9742048631f82de7 /contrib/persistent-https
parented693078e988adf66c969feb6de9f83c7abe7d24 (diff)
downloadgit-7174098834e30d2da1834bbfd0aaf575f6d6bb1a.tar.gz
git-7174098834e30d2da1834bbfd0aaf575f6d6bb1a.zip
pack-bitmap: fix bug with exact ref match in "pack.preferBitmapTips"
The "pack.preferBitmapTips" configuration allows the user to specify which references should be preferred when generating bitmaps. This option is typically expected to be set to a reference prefix, like for example "refs/heads/". It's not unreasonable though for a user to configure one specific reference as preferred. But if they do, they'll hit a `BUG()`: $ git -c pack.preferBitmapTips=refs/heads/main repack -adb BUG: ../refs/iterator.c:366: attempt to trim too many characters error: pack-objects died of signal 6 The root cause for this bug is how we enumerate these references. We call `refs_for_each_ref_in()`, which will: - Yield all references that have a user-specified prefix. - Trim each of these references so that the prefix is removed. Typically, this function is called with a trailing slash, like "refs/heads/", and in that case things work alright. But if the function is called with the name of an existing reference then we'll try to trim the full reference name, which would leave us with an empty name. And as this would not really leave us with anything sensible, we call `BUG()` instead of yielding this reference. One could argue that this is a bug in `refs_for_each_ref_in()`. But the question then becomes what the correct behaviour would be: - Do we want to skip exact matches? In our case we certainly don't want that, as the user has asked us to generate a bitmap for it. - Do we want to yield the reference with the empty refname? That would lead to a somewhat weird result. Neither of these feel like viable options, so calling `BUG()` feels like a sensible way out. The root cause ultimately is that we even try to trim the whole refname in the first place. There are two possible ways to fix this issue: - We can fix the bug by using `refs_for_each_fullref_in()` instead, which does not strip the prefix at all. Consequently, we would now start to accept all references that start with the configured prefix, including exact matches. So if we had "refs/heads/main", we would both match "refs/heads/main" and "refs/heads/main-branch". - Or we can fix the bug by appending a slash to the prefix if it doesn't already have one. This would mean that we only match ref hierarchies that start with this prefix. While the first fix leaves the user with strictly _more_ configuration options, we have already fixed a similar case in 10e8a9352b (refs.c: stop matching non-directory prefixes in exclude patterns, 2025-03-06) by using the second option. So for the sake of consistency, let's apply the same fix here. Clarify the documentation accordingly. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/persistent-https')
0 files changed, 0 insertions, 0 deletions