git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.

  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).