All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Clemens Fruhwirth <clemens@endorphin.org>
Cc: git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>,
	"Jan Pokorný" <poki@fnusa.cz>,
	"Corentin BOMPARD" <corentin.bompard@etu.univ-lyon1.fr>
Subject: Re: [PATCH v2] pull, fetch: fix segfault in --set-upstream option
Date: Tue, 24 Aug 2021 10:49:26 +0200	[thread overview]
Message-ID: <87bl5nfcof.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAG6gW_s6FHG6muJ6Hai-Sb2ntmygLymQZr8YrN212_SV1VhBAw@mail.gmail.com>


On Tue, Aug 24 2021, Clemens Fruhwirth wrote:

> On Mon, 23 Aug 2021 at 14:56, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
>>
>> A proposed replacement of cf/fetch-set-upstream-while-detached which
>> as noted in What's Cooking has been languishing for a while. I changed
>> the die() in my version to a warning() as suggested by Junio & updated
>> the test and commit message accordingly.
>
> Thank you Ævar, for taking care of that and adding tests and my
> apologizes for not responding in a timely manner.

No worries.

>>  builtin/fetch.c         | 11 +++++++++++
>>  t/t5553-set-upstream.sh | 22 ++++++++++++++++++++++
>>  2 files changed, 33 insertions(+)
>>
>> diff --git a/builtin/fetch.c b/builtin/fetch.c
>> index 25740c13df1..ca487edd805 100644
>> --- a/builtin/fetch.c
>> +++ b/builtin/fetch.c
>> @@ -1623,6 +1623,17 @@ static int do_fetch(struct transport *transport,
>>                         }
>>                 }
>>                 if (source_ref) {
>> +                       if (!branch) {
>> +                               const char *shortname = NULL;
>> +                               if (!skip_prefix(source_ref->name,
>> +                                                "refs/heads/", &shortname))
>> +                                       shortname = source_ref->name;
>
> Is skip_prefix ever able to fail?
>
> - If yes, then shortname will be left pointing to NULL when we print
> the warning below. Warning probably won't die because of NULL, but it
> still will print something weird.

If it fails we'll use source_ref->name, so it won't be NULL...

> - If no, then an assert(!skip_prefix(source_ref->name, "refs/heads/",
> &shortname)) might be more idiomatic.

Which means that this would be a bug, since it's not handling the case
where the source doesn't start with refs/heads/*.

I.e. it's the same as doing it this way (on top of this v2), which
perhaps is a clearer way to express the same idea. What do you think?

diff --git a/builtin/fetch.c b/builtin/fetch.c
index ca487edd805..2bc9159690d 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -1624,10 +1624,9 @@ static int do_fetch(struct transport *transport,
 		}
 		if (source_ref) {
 			if (!branch) {
-				const char *shortname = NULL;
-				if (!skip_prefix(source_ref->name,
-						 "refs/heads/", &shortname))
-					shortname = source_ref->name;
+				const char *shortname = source_ref->name;
+				skip_prefix(shortname, "refs/heads/", &shortname);
+
 				warning(_("could not set upstream of HEAD to '%s' from '%s' when "
 					  "it does not point to any branch."),
 					shortname, transport->remote->name);

  reply	other threads:[~2021-08-24  8:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-05 15:46 git pull --set-upstream segfaults on branchless repo Clemens Fruhwirth
2021-07-19 10:04 ` Jan Pokorný
2021-07-19 14:30   ` [PATCH] pull, fetch: fix segfault in --set-upstream option Ævar Arnfjörð Bjarmason
2021-07-19 15:17     ` Junio C Hamano
2021-08-23 12:56     ` [PATCH v2] " Ævar Arnfjörð Bjarmason
2021-08-24  7:30       ` Clemens Fruhwirth
2021-08-24  8:49         ` Ævar Arnfjörð Bjarmason [this message]
2021-08-30 14:41       ` [PATCH v3] " Ævar Arnfjörð Bjarmason
2021-08-30 17:46         ` Junio C Hamano
2021-08-31 13:58         ` [PATCH v4] " Ævar Arnfjörð Bjarmason
2021-08-31 16:40           ` Junio C Hamano
2021-08-31 20:20             ` Ævar Arnfjörð Bjarmason
2021-09-01 17:44               ` Junio C Hamano

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=87bl5nfcof.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=clemens@endorphin.org \
    --cc=corentin.bompard@etu.univ-lyon1.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=poki@fnusa.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.