From: Junio C Hamano <gitster@pobox.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, Kyle Lippincott <spectral@google.com>
Subject: Re: [PATCH 1/2] config: fix segfault when parsing "core.abbrev" without repo
Date: Tue, 11 Jun 2024 10:54:23 -0700 [thread overview]
Message-ID: <xmqqh6dzwek0.fsf@gitster.g> (raw)
In-Reply-To: <7ded51bbce1b23cf4110e3bf0abb7579efd4d344.1718095090.git.ps@pks.im> (Patrick Steinhardt's message of "Tue, 11 Jun 2024 10:42:02 +0200")
Patrick Steinhardt <ps@pks.im> writes:
> 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.
Makes sense.
> diff --git a/config.c b/config.c
> index abce05b774..ab2844d9e1 100644
> --- a/config.c
> +++ b/config.c
> @@ -1460,11 +1460,14 @@ static int git_default_core_config(const char *var, const char *value,
> if (!strcasecmp(value, "auto"))
> 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;
We will need to have some code that further adjusts overly long
default_abbrev when we really have to abbreviate (at which time,
hopefully we are already aware of the real hash algorithm used in
the repository, and that may be SHA-1) anyway.
So do we even need the conditional here? Can't we just set it to
GIT_MAX_HEXSZ here unconditionally?
> diff --git a/t/t4202-log.sh b/t/t4202-log.sh
> index 86c695eb0a..99c063e4cd 100755
> --- a/t/t4202-log.sh
> +++ b/t/t4202-log.sh
> @@ -1237,6 +1237,12 @@ test_expect_success 'log.abbrevCommit configuration' '
> test_cmp expect.whatchanged.full actual
> '
>
> +test_expect_success 'log.abbrevCommit with --abbrev=9000' '
> + git log --no-abbrev >expect &&
> + git log --abbrev-commit --abbrev=9000 >actual &&
> + test_cmp expect actual
> +'
Interesting. We didn't have coverage for "we want to see full
object names" case.
> +test_expect_success 'output from clone with core.abbrev does not crash' '
> + rm -fr dst &&
> + echo "Cloning into ${SQ}dst${SQ}..." >expect &&
> + git -c core.abbrev=12 clone -n "file://$(pwd)/src" dst >actual 2>&1 &&
> + test_cmp expect actual
> +'
OK.
next prev parent reply other threads:[~2024-06-11 17:54 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 [this message]
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 ` [PATCH v2 0/3] config: fix segfault when parsing "core.abbrev" without repo Patrick Steinhardt
2024-06-12 8:03 ` [PATCH v2 1/3] " 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=xmqqh6dzwek0.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=ps@pks.im \
--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).