From: Patrick Steinhardt <ps@pks.im>
To: git@vger.kernel.org
Cc: Kyle Lippincott <spectral@google.com>,
Junio C Hamano <gitster@pobox.com>
Subject: [PATCH v2 0/3] config: fix segfault when parsing "core.abbrev" without repo
Date: Wed, 12 Jun 2024 10:03:18 +0200 [thread overview]
Message-ID: <cover.1718178996.git.ps@pks.im> (raw)
In-Reply-To: <CAO_smVimsHAPbMxy09mcYZY8apFgCbpnS9eSF7UOL6_BLqntNw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4035 bytes --]
Hi,
this is the second version of my patch series that fixes a segfault when
parsing "core.abbrev" without a repository.
Changes compared to v1:
- Stop truncating the abbreviation length to the upper boundary
completely. It's unnecessary, complicates the code and makes us
dependent on `the_repository`.
- Adapt `parse_opt_abbrev_cb()` to also stop truncating such that the
behaviour of "core.abbrev" and `--abbrev` is the same.
- Extend test coverage a bit.
Thanks!
Patrick
Patrick Steinhardt (3):
config: fix segfault when parsing "core.abbrev" without repo
parse-options-cb: stop clamping "--abbrev=" to hash length
object-name: don't try to abbreviate to lengths greater than hexsz
config.c | 4 ++--
object-name.c | 2 +-
parse-options-cb.c | 2 --
t/t4202-log.sh | 24 ++++++++++++++++++++++++
t/t5601-clone.sh | 7 +++++++
5 files changed, 34 insertions(+), 5 deletions(-)
Range-diff against v1:
1: 7ded51bbce ! 1: b48c50dd92 config: fix segfault when parsing "core.abbrev" without repo
@@ Commit message
`the_hash_algo` outside of Git repositories.
Fix both of these issues by not making it an error anymore when the
- given length exceeds the hash length. Instead, if we have a repository,
- then we truncate the length to the maximum length of `the_hash_algo`.
- Otherwise, we simply leave the abbreviated length intact and store it
- as-is. This is equivalent to the logic in `parse_opt_abbrev_cb()` and is
- handled just fine by `repo_find_unique_abbrev_r()`. In practice, we
- should never even end up using `default_abbrev` without a repository
- anyway given that abbreviating object IDs to unique prefixes requires us
- to have access to an object database.
+ given length exceeds the hash length. Instead, leave the abbreviated
+ length intact. `repo_find_unique_abbrev_r()` handles this just fine
+ except for a performance penalty which we will fix in a subsequent
+ commit.
Reported-by: Kyle Lippincott <spectral@google.com>
Signed-off-by: Patrick Steinhardt <ps@pks.im>
@@ config.c: static int git_default_core_config(const char *var, const char *value,
default_abbrev = -1;
else if (!git_parse_maybe_bool_text(value))
- default_abbrev = the_hash_algo->hexsz;
-+ default_abbrev = startup_info->have_repository ?
-+ the_hash_algo->hexsz : GIT_MAX_HEXSZ;
++ default_abbrev = GIT_MAX_HEXSZ;
else {
int abbrev = git_config_int(var, value, ctx->kvi);
- if (abbrev < minimum_abbrev || abbrev > the_hash_algo->hexsz)
+ if (abbrev < minimum_abbrev)
return error(_("abbrev length out of range: %d"), abbrev);
-+ else if (startup_info->have_repository && abbrev > the_hash_algo->hexsz)
-+ abbrev = the_hash_algo->hexsz;
default_abbrev = abbrev;
}
- return 0;
## t/t4202-log.sh ##
@@ t/t4202-log.sh: test_expect_success 'log.abbrevCommit configuration' '
test_cmp expect.whatchanged.full actual
'
-+test_expect_success 'log.abbrevCommit with --abbrev=9000' '
++test_expect_success '--abbrev-commit with core.abbrev=false' '
+ git log --no-abbrev >expect &&
-+ git log --abbrev-commit --abbrev=9000 >actual &&
++ git -c core.abbrev=false log --abbrev-commit >actual &&
++ test_cmp expect actual
++'
++
++test_expect_success '--abbrev-commit with core.abbrev=9000' '
++ git log --no-abbrev >expect &&
++ git -c core.abbrev=9000 log --abbrev-commit >actual &&
+ test_cmp expect actual
+'
+
-: ---------- > 2: 92860256a6 parse-options-cb: stop clamping "--abbrev=" to hash length
2: 31c0405f85 = 3: 0ccb8d8efa object-name: don't try to abbreviate to lengths greater than hexsz
--
2.45.2.457.g8d94cfb545.dirty
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-06-12 8:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-10 22:27 SEGV (detected by Address Sanitizer) when using `core.abbrev` option Kyle Lippincott
2024-06-10 23:01 ` Kyle Lippincott
2024-06-10 23:21 ` Junio C Hamano
2024-06-11 6:06 ` Patrick Steinhardt
2024-06-11 8:42 ` [PATCH 1/2] config: fix segfault when parsing "core.abbrev" without repo Patrick Steinhardt
2024-06-11 17:54 ` Junio C Hamano
2024-06-12 5:55 ` Patrick Steinhardt
2024-06-11 8:42 ` [PATCH 2/2] object-name: don't try to abbreviate to lengths greater than hexsz Patrick Steinhardt
2024-06-12 8:03 ` Patrick Steinhardt [this message]
2024-06-12 8:03 ` [PATCH v2 1/3] config: fix segfault when parsing "core.abbrev" without repo Patrick Steinhardt
2024-06-12 9:22 ` Karthik Nayak
2024-06-12 8:03 ` [PATCH v2 2/3] parse-options-cb: stop clamping "--abbrev=" to hash length Patrick Steinhardt
2024-06-12 8:03 ` [PATCH v2 3/3] object-name: don't try to abbreviate to lengths greater than hexsz Patrick Steinhardt
2024-06-12 9:29 ` [PATCH v2 0/3] config: fix segfault when parsing "core.abbrev" without repo Karthik Nayak
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=cover.1718178996.git.ps@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=spectral@google.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;
as well as URLs for NNTP newsgroup(s).