On Thu, Jul 4, 2024 at 1:00 PM Karthik Nayak <karthik.188@xxxxxxxxx> wrote:
>
> Eric Ju <eric.peijian@xxxxxxxxx> writes:
>
> > From: Calvin Wan <calvinwan@xxxxxxxxxx>
> >
> > A subsequent patch need to write capabilities for another command.
>
> s/need/needs
Thank you. Fixed in v2.
> > Refactor write_fetch_command_and_capabilities() to be used by both
> > fetch and future command.
> >
>
> Nit: mostly from my lack of understanding, but until I read the code, I
> couldn't understand what 'command' meant in this para. Maybe some
> preface would be nice here.
>
Thank you. I will add this in v2 commit message.
Here "command" means the "operations" supported by Git’s wire protocol
https://git-scm.com/docs/protocol-v2. An example would be a
git's subcommand, such as git-fetch(1); or an operation supported by
the server side such as "object-info" implemented at "a2ba162cda
(object-info: support for retrieving object info, 2021-04-20)".
> > Signed-off-by: Calvin Wan <calvinwan@xxxxxxxxxx>
> > Signed-off-by: Eric Ju <eric.peijian@xxxxxxxxx>
> > Helped-by: Jonathan Tan <jonathantanmy@xxxxxxxxxx>
> > Helped-by: Christian Couder <chriscool@xxxxxxxxxxxxx>
> > ---
> > fetch-pack.c | 12 ++++++------
> > 1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/fetch-pack.c b/fetch-pack.c
> > index eba9e420ea..fc9fb66cd8 100644
> > --- a/fetch-pack.c
> > +++ b/fetch-pack.c
> > @@ -1313,13 +1313,13 @@ static int add_haves(struct fetch_negotiator *negotiator,
> > return haves_added;
> > }
> >
> > -static void write_fetch_command_and_capabilities(struct strbuf *req_buf,
> > - const struct string_list *server_options)
> > +static void write_command_and_capabilities(struct strbuf *req_buf,
> > + const struct string_list *server_options, const char* command)
> > {
> > const char *hash_name;
> >
> > - ensure_server_supports_v2("fetch");
> > - packet_buf_write(req_buf, "command=fetch");
> > + ensure_server_supports_v2(command);
> > + packet_buf_write(req_buf, "command=%s", command);
> > if (server_supports_v2("agent"))
> > packet_buf_write(req_buf, "agent=%s", git_user_agent_sanitized());
> > if (advertise_sid && server_supports_v2("session-id"))
> > @@ -1355,7 +1355,7 @@ static int send_fetch_request(struct fetch_negotiator *negotiator, int fd_out,
> > int done_sent = 0;
> > struct strbuf req_buf = STRBUF_INIT;
> >
> > - write_fetch_command_and_capabilities(&req_buf, args->server_options);
> > + write_command_and_capabilities(&req_buf, args->server_options, "fetch");
> >
> > if (args->use_thin_pack)
> > packet_buf_write(&req_buf, "thin-pack");
> > @@ -2163,7 +2163,7 @@ void negotiate_using_fetch(const struct oid_array *negotiation_tips,
> > the_repository, "%d",
> > negotiation_round);
> > strbuf_reset(&req_buf);
> > - write_fetch_command_and_capabilities(&req_buf, server_options);
> > + write_command_and_capabilities(&req_buf, server_options, "fetch");
> >
> > packet_buf_write(&req_buf, "wait-for-done");
> >
> > --
> > 2.45.2
>
> Right, this commit in itself looks good. But I was curious why we need
> this, so I did a sneak peak into the following commits.
>
> To summarize, we want to call:
> `write_command_and_capabilities(..., "object-info");`
> in the upcoming patches to get the object-info details from the server.
> But isn't this function too specific to the "fetch" command to be
> generalized to be for "object-info" too?
>
> Wouldn't it make sense to add a custom function for 'object-info' in
> 'connect.c'? Like how we currently have `get_remote_bundle_uri()` for
> 'bundle-uri' and `get_remote_refs` for 'ls-refs'?
Thank you. I am reading through the old comments left by Taylor
at https://lore.kernel.org/git/YkOPyc9tUfe2Tozx@nand.local/
" Makes obvious sense, and this was something that jumped out to me when I
looked at the first and second versions of this patch. I'm glad that
this is getting factored out."
It seems refactoring this into a more general function is on purpose.
It is encouraged to use this general function to request capability
rather than adding a custom function.
Taylor’s comment was 2 years ago, but I think refactoring this into a
more general function to
enforce DRY still makes sense.
