All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Jonathan Tan <jonathantanmy@google.com>
Cc: emilyshaffer@google.com, git@vger.kernel.org
Subject: Re: [PATCH 3/3] fetch: die on invalid --negotiation-tip hash
Date: Wed, 14 Jul 2021 23:45:24 +0200	[thread overview]
Message-ID: <87sg0gzhys.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <20210714193506.4084421-1-jonathantanmy@google.com>


On Wed, Jul 14 2021, Jonathan Tan wrote:

>> >> diff --git a/builtin/fetch.c b/builtin/fetch.c
>> >> index 9191620e50..2c50465cff 100644
>> >> --- a/builtin/fetch.c
>> >> +++ b/builtin/fetch.c
>> >> @@ -1428,7 +1428,9 @@ static void add_negotiation_tips(struct git_transport_options *smart_options)
>> >>  		if (!has_glob_specials(s)) {
>> >>  			struct object_id oid;
>> >>  			if (get_oid(s, &oid))
>> >> -				die("%s is not a valid object", s);
>> >> +				die(_("%s is not a valid object"), s);
>> >> +			if (!has_object(the_repository, &oid, 0))
>> >> +				die(_("%s is not a valid object"), s);
>> > Any reason not to consolidate these, e.g. if (get_oid || !has_object)?
>> > Then we wouldn't dup the err string.
>> 
>> Generally I'd agree, but aren't we explicitly conflating cases where
>> something is a valid way no name an object v.s. being certain that such
>> an object does not exist? I.e. this should be something like:
>> 
>>     if can't get_get():
>>         error "couldn't get the OID of revision '%s'"
>>     if can't look up fully-qualified OID:
>>         error "the OID '%s' does not exist"
>> 
>> Or something...
>
> Good point. I'll use wording similar to yours.

I stole the former from a quick grepping around:

    builtin/bisect--helper.c: res = error(_("couldn't get the oid of the rev '%s'"), rev)

Then http-push.c suggests "perhaps you need to fetch" for
has_object_file(), but I don't know if it applies here...

  reply	other threads:[~2021-07-14 21:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-23 22:30 [PATCH 0/3] Push negotiation fixes Jonathan Tan
2021-06-23 22:30 ` [PATCH 1/3] send-pack: fix push.negotiate with remote helper Jonathan Tan
2021-07-13 22:23   ` Emily Shaffer
2021-07-14 19:25     ` Jonathan Tan
2021-07-13 23:11   ` Ævar Arnfjörð Bjarmason
2021-07-14 19:32     ` Jonathan Tan
2021-07-14 21:51       ` Ævar Arnfjörð Bjarmason
2021-06-23 22:30 ` [PATCH 2/3] send-pack: fix push nego. when remote has refs Jonathan Tan
2021-07-13 22:30   ` Emily Shaffer
2021-07-14 19:33     ` Jonathan Tan
2021-06-23 22:30 ` [PATCH 3/3] fetch: die on invalid --negotiation-tip hash Jonathan Tan
2021-07-13 22:36   ` Emily Shaffer
2021-07-13 23:34     ` Ævar Arnfjörð Bjarmason
2021-07-14 19:35       ` Jonathan Tan
2021-07-14 21:45         ` Ævar Arnfjörð Bjarmason [this message]
2021-07-15 17:44 ` [PATCH v2 0/3] Push negotiation fixes Jonathan Tan
2021-07-15 17:44   ` [PATCH v2 1/3] send-pack: fix push.negotiate with remote helper Jonathan Tan
2021-07-27  7:56     ` Ævar Arnfjörð Bjarmason
2021-07-15 17:44   ` [PATCH v2 2/3] send-pack: fix push nego. when remote has refs Jonathan Tan
2021-07-27  8:09     ` Ævar Arnfjörð Bjarmason
2021-07-27 16:46       ` Jeff King
2021-07-27 21:11       ` Jonathan Tan
2021-07-15 17:44   ` [PATCH v2 3/3] fetch: die on invalid --negotiation-tip hash Jonathan Tan
2021-07-15 19:03   ` [PATCH v2 0/3] Push negotiation fixes 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=87sg0gzhys.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=emilyshaffer@google.com \
    --cc=git@vger.kernel.org \
    --cc=jonathantanmy@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 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.