On Thu, May 18, 2023 at 08:18:03PM -0400, Jeff King wrote:

On Wed, May 17, 2023 at 01:48:51PM +0200, Patrick Steinhardt wrote:

quoted

The `fetch_config` structure currently only has a single member, which
is the `display_format`. We're about extend it to contain all parsed
config values and will thus need it available in most of the code.

Prepare for this change by passing through the `fetch_config` directly
instead of only passing its single member.

Makes sense.

One small nit:

quoted

 static int do_fetch(struct transport *transport,
 		    struct refspec *rs,
-		    enum display_format display_format)
+		    const struct fetch_config *config)
 {
 	struct ref_transaction *transaction = NULL;
 	struct ref *ref_map = NULL;

@@ -1639,7 +1639,8 @@ static int do_fetch(struct transport *transport,
 	if (retcode)
 		goto cleanup;
 
-	display_state_init(&display_state, ref_map, transport->url, display_format);
+	display_state_init(&display_state, ref_map, transport->url,
+			   config->display_format);

If the point is that fetch_config may start carrying new information,
wouldn't we want to pass it as a whole down to display_state_init()? It
might eventually want to see some of that other config, too.

It's presumably academic for now, and it would not be too hard to change
later if needed, so I don't know that it's worth a re-roll. I just found
it especially funny here since the purpose of the patch is to treat the
config struct as a single unit.

Well, I decided against passing in the full configuration as it feels a
bit like a layering violation: the other code really is about the fetch
itself, while this code here is only about display logic. So passing in
the `fetch_config` felt weird to me, even more so because we continue to
only need that single value at the end of this series. I do see your
point though.

Given that none of your other comments require a reroll I'll leave this
as-is for now. Thanks for your review!

Patrick