From: "Eric W. Biederman" <ebiederm@gmail.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, "brian m. carlson" <sandals@crustytoothpaste.net>
Subject: Re: [PATCH 0/3] some transport-helper "option object-format" confusion
Date: Wed, 20 Mar 2024 12:05:49 -0500 [thread overview]
Message-ID: <87y1ac3kb6.fsf@gmail.froward.int.ebiederm.org> (raw)
In-Reply-To: <20240320093226.GA2445531@coredump.intra.peff.net> (Jeff King's message of "Wed, 20 Mar 2024 05:32:26 -0400")
Jeff King <peff@peff.net> writes:
> On Thu, Mar 07, 2024 at 03:47:35AM -0500, Jeff King wrote:
>
>> I happened to be looking at the output of t5801 for an unrelated
>> problem, and I noticed our git-remote-testgit spewing a bunch of shell
>> errors. It turns out that its expectations do not quite match what the
>> transport-helper code produces.
>>
>> This series brings the test and documentation in line with how the
>> transport-helper code behaves. But I'm not sure if we should be going
>> the other way (see the comments on patch 2 especially), and bringing the
>> transport-helper code in line with the others. Hence the RFC.
>>
>> [1/2]: t5801: fix object-format handling in git-remote-testgit
>> [2/2]: doc/gitremote-helpers: match object-format option docs to code
>
> Here's a non-RFC v2 based on the discussion thus far (thanks brian and
> Eric).
>
> The big change is that instead of changing the docs to match true-less
> "option object-format", the code is changed to match the docs. That
> happens in patch 3 (which subsumes the original patch 1). We continue to
> drop the documentation for the "option object-format sha256" form. But
> now the commit message justifies it better, and we clean up the stale
> code in remote-curl.c.
>
> Patch 1 is a small fix for debugging output that I noticed after getting
> confused. :-/ It's not strictly related and could be taken separately.
>
> Eric mentioned having Git check that the helpers never say
> ":object-format" unless it was negotiated. I stopped short of that. One,
> it's a bit tricky to test (since Git will always ask for object-format,
> you have to teach remote-testgit to optionally send broken output). And
> two, I'm not sure that being strict has much value here. It keeps remote
> helpers honest, but the real losers are old versions that do not
> understand :object-format, which would fail against such a remote. So I
> dunno. It isn't any harder to do it on top later if we want to.
Your sentence has what I was asking for backwards. It would be healthy
if the code fails when "object-format" has been advertised by the
remote, requested by the transport-helper, and the remote does not send
":object-format".
The check is cheap and should prevent buggy remotes from appearing in
the wild. I am probably biased but I rather want the information
on what hash algorithm the remote is using when I ask for it.
I can totally imagine someone during development forgetting to send
:object-format and either not noticing something was wrong, or spending
a fair amount of time debugging that they forgot to send it.
It is the kind of bug I can imagine someone making when they are called
away from the keyboard at the wrong moment.
The implementation should just be:
diff --git a/transport-helper.c b/transport-helper.c
index b660b7942f9f..e648f136287d 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -1206,6 +1206,7 @@ static struct ref *get_refs_list_using_list(struct transport *transport,
struct ref **tail = &ret;
struct ref *posn;
struct strbuf buf = STRBUF_INIT;
+ bool received_object_format = false;
data->get_refs_list_called = 1;
helper = get_helper(transport);
@@ -1236,9 +1236,13 @@ static struct ref *get_refs_list_using_list(struct transport *transport,
die(_("unsupported object format '%s'"),
value);
transport->hash_algo = &hash_algos[algo];
+ received_object_format = true;
}
continue;
}
+ else if (data->object_format && !received_object_format) {
+ die(_("missing :object-format"));
+ }
eov = strchr(buf.buf, ' ');
if (!eov)
Am I missing something that makes a bad implementation?
Hmm. I thought gitremote-helpers.txt said the key value pairs
would precede everything else from a list command.
gitremote-helpers.txt does not mention that. That looks like
a Documentation oversight.
However remote-curl.c in output_refs prints :object-format before
anything else, and transport-helper.c will malfunction if :object-format
is sent after any of the refs. As transport->hash_algop is used by
get_oid_hex_algop is used to parse the oids of the refs.
We can probably fix the Documentation like:
diff --git a/Documentation/gitremote-helpers.txt b/Documentation/gitremote-helpers.txt
index ed8da428c98b..b6ca29a245f3 100644
--- a/Documentation/gitremote-helpers.txt
+++ b/Documentation/gitremote-helpers.txt
@@ -268,6 +268,8 @@ Support for this command is mandatory.
ref. A space-separated list of attributes follows the name;
unrecognized attributes are ignored. The list ends with a
blank line.
+
+ Keywords should precede everything else in the list.
+
See REF LIST ATTRIBUTES for a list of currently defined attributes.
See REF LIST KEYWORDS for a list of currently defined keywords.
I do agree that the sanity check can be added to your series, so if you
would prefer I can do that.
Eric
next prev parent reply other threads:[~2024-03-20 17:06 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-07 8:47 [RFC/PATCH 0/2] some transport-helper "option object-format" confusion Jeff King
2024-03-07 8:51 ` [PATCH 1/2] t5801: fix object-format handling in git-remote-testgit Jeff King
2024-03-07 8:56 ` [PATCH 2/2] doc/gitremote-helpers: match object-format option docs to code Jeff King
2024-03-07 22:20 ` brian m. carlson
2024-03-12 7:45 ` Jeff King
2024-03-13 21:11 ` brian m. carlson
2024-03-14 12:47 ` Eric W. Biederman
2024-03-14 21:21 ` brian m. carlson
2024-03-15 15:41 ` Eric W. Biederman
2024-03-16 6:04 ` Jeff King
2024-03-17 20:47 ` Eric W. Biederman
2024-03-18 8:49 ` Jeff King
2024-03-14 15:33 ` Junio C Hamano
2024-03-14 21:54 ` brian m. carlson
2024-03-20 9:32 ` [PATCH 0/3] some transport-helper "option object-format" confusion Jeff King
2024-03-20 9:34 ` [PATCH 1/3] transport-helper: use write helpers more consistently Jeff King
2024-03-20 9:37 ` [PATCH 2/3] transport-helper: drop "object-format <algo>" option Jeff King
2024-03-20 9:41 ` [PATCH 3/3] transport-helper: send "true" value for object-format option Jeff King
2024-03-20 17:23 ` Junio C Hamano
2024-03-20 17:05 ` Eric W. Biederman [this message]
2024-03-27 9:48 ` [PATCH 0/3] some transport-helper "option object-format" confusion Jeff King
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y1ac3kb6.fsf@gmail.froward.int.ebiederm.org \
--to=ebiederm@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sandals@crustytoothpaste.net \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).