[1/6] fetch-pack: refactor packet writing

Commit Message

Eric Ju June 28, 2024, 7:04 p.m. UTC

From: Calvin Wan <[e-mail]>

A subsequent patch need to write capabilities for another command.
Refactor write_fetch_command_and_capabilities() to be used by both
fetch and future command.

Signed-off-by: Calvin Wan <[e-mail]>
Signed-off-by: Eric Ju  <[e-mail]>
Helped-by: Jonathan Tan <[e-mail]>
Helped-by: Christian Couder <[e-mail]>
---
 fetch-pack.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

Comments

Karthik Nayak July 4, 2024, 4:59 p.m. UTC | #1

Eric Ju <[e-mail]> writes:

> From: Calvin Wan <[e-mail]>
>
> A subsequent patch need to write capabilities for another command.

s/need/needs

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

> Signed-off-by: Calvin Wan <[e-mail]>
> Signed-off-by: Eric Ju  <[e-mail]>
> Helped-by: Jonathan Tan <[e-mail]>
> Helped-by: Christian Couder <[e-mail]>
> ---
>  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'?

Eric Ju July 8, 2024, 3:17 p.m. UTC | #2

On Thu, Jul 4, 2024 at 1:00 PM Karthik Nayak <[e-mail]> wrote:
>
> Eric Ju <[e-mail]> writes:
>
> > From: Calvin Wan <[e-mail]>
> >
> > 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 <[e-mail]>
> > Signed-off-by: Eric Ju  <[e-mail]>
> > Helped-by: Jonathan Tan <[e-mail]>
> > Helped-by: Christian Couder <[e-mail]>
> > ---
> >  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/[e-mail]/

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

Karthik Nayak July 10, 2024, 9:39 a.m. UTC | #3

Peijian Ju <[e-mail]> writes:
[snip]

>> 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/[e-mail]/
>
>   " 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.

It would make sense then to move the existing users to also use
`write_command_and_capabilities` eventually. I guess this could be done
in a follow up series.

Then I would say `write_command_and_capabilities()` should be moved to
`transport.c`, no?

Eric Ju July 15, 2024, 4:40 p.m. UTC | #4

On Wed, Jul 10, 2024 at 5:39 AM Karthik Nayak <[e-mail]> wrote:
>
> Peijian Ju <[e-mail]> writes:
> [snip]
>
> >> 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/[e-mail]/
> >
> >   " 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.
>
> It would make sense then to move the existing users to also use
> `write_command_and_capabilities` eventually. I guess this could be done
> in a follow up series.
>
> Then I would say `write_command_and_capabilities()` should be moved to
> `transport.c`, no?

Thank you. I am not sure about this. Currently, the file dependency is
like this:
`transport.c`  -> `fetch-pack.c` -> `connect.c`  where "->" means "depends on".

Moving `write_command_and_capabilities()` to `transport.c` would make
circle dependency.

If we want `write_command_and_capabilities()` to be a more general
utility function,
it seems make more sense to move it to `connect.c`. I saw a bunch of
these general utility functions
in `connect.c` such as `send_capabilities()`. Some custom functions
such as `get_remote_bundle_uri()` and `get_remote_refs`also lives in
it.

Please let me know what you think. Thanks.

Patch

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");