[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH 8/8] upload-pack: send part of packfile response as uri
From:       Junio C Hamano <gitster () pobox ! com>
Date:       2020-05-31 17:35:27
Message-ID: xmqq367gvwgw.fsf () gitster ! c ! googlers ! com
[Download RAW message or body]

Jonathan Tan <jonathantanmy@google.com> writes:

>  static void create_pack_file(const struct object_array *have_obj,
>  			     const struct object_array *want_obj,
> -			     struct list_objects_filter_options *filter_options)
> +			     struct list_objects_filter_options *filter_options,
> +			     const struct string_list *uri_protocols)
>  {

I wanted to see why you rebased on top of 'next' to see possible
interactions with topics in-flight, and I found out that this series
was trivial to rebase on 'master'.

The codebase however is moving in the direction to reduce the number
of parameters this function takes, and the above change does not
play well with the cc/upload-pack-data-2 topic that cleans up the
code around this area.

Can you help review cc/upload-pack-data and cc/upload-pack-data-2
topics, as you'd eventually be basing your topic on top of the
result of merging these two clean-up topics to 'master'?  The former
is already in 'next' after Peff's review, and after finding nothing
glaringly wrong in it, I am not so worried about it, but the latter
may benefit from an extra set of eyes.

Thanks.


[prev in list] [next in list] [prev in thread] [next in thread]