Thread (30 messages) 30 messages, 2 authors, 2021-09-05

Re: [PATCH v2 2/4] bundle API: change "flags" to be "extra_index_pack_args"

From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2021-08-24 21:45:26

On Tue, Aug 24 2021, Derrick Stolee wrote:
On 8/23/2021 7:02 AM, Ævar Arnfjörð Bjarmason wrote:
...
quoted
--- a/builtin/bundle.c
+++ b/builtin/bundle.c
@@ -165,7 +165,8 @@ static int cmd_bundle_unbundle(int argc, const char **argv, const char *prefix)
 	struct option options[] = {
 		OPT_END()
 	};
-	char *bundle_file;
+	char* bundle_file;
nit: errant movement of "*" here.
Ah, thanks.
quoted
+	struct strvec extra_args = STRVEC_INIT;
...
quoted
-	ret = !!unbundle(the_repository, &header, bundle_fd, 0) ||
+	ret = !!unbundle(the_repository, &header, bundle_fd, &extra_args) ||
I'm assuming that you will be adding something that adds to extra_args
in a future commit. It might be better to just convert the "0" to "NULL"
here and add extra_args when you actually use it.
*nod*, commented on in the later commit.
quoted
 int unbundle(struct repository *r, struct bundle_header *header,
-	     int bundle_fd, int flags)
+	     int bundle_fd, struct strvec *extra_index_pack_args)
 {
-	const char *argv_index_pack[] = {"index-pack",
-					 "--fix-thin", "--stdin", NULL, NULL};
 	struct child_process ip = CHILD_PROCESS_INIT;
+	int i;
 
-	if (flags & BUNDLE_VERBOSE)
-		argv_index_pack[3] = "-v";
+	strvec_push(&ip.args, "index-pack");
+	strvec_push(&ip.args, "--fix-thin");
+	strvec_push(&ip.args, "--stdin");
+	if (extra_index_pack_args) {
+		struct strvec *extra = extra_index_pack_args;
Creating a shorter variable name seems unnecessary.
Will skip it.
quoted
+		for (i = 0; i < extra->nr; i++)
+			strvec_push(&ip.args, extra->v[i]);
This seems like a good opportunity to create and use a
strvec_concat() method.
Yeah, I guess I could start with that. Will try it.
quoted
+		strvec_clear(extra_index_pack_args);
Why is it the responsibility of this method to clear these args?
I suppose it is convenient. It just seems a bit wrong to me.
Because of...
quoted
 /**
  * Unbundle after reading the header with read_bundle_header().
  *
  * We'll invoke "git index-pack --stdin --fix-thin" for you on the
  * provided `bundle_fd` from read_bundle_header().
+ *
+ * Provide extra_index_pack_args to pass any extra arguments
+ * (e.g. "-v" for verbose/progress), NULL otherwise. The provided
+ * extra_index_pack_args (if any) will be strvec_clear()'d for you
+ * (like the run-command.h API itself does).
... this, i.e. it's how the run-command.[ch] API already works for the
same sort of thing elsewhere, I figured making them consistent was
better than having them differ.

I think that while in general the rule of having each function allocate
& clear its own memory is a good one, that a notable good exception in
our codebase is various "one-shot" functions such as the run-command
API, i.e. APIs where the vast majority of callers just want to set
things up for a one-off run. Having those common cases not require a
that_api_release(&ctx) afterwards seems like a good idea in general.
quoted
  */
 int unbundle(struct repository *r, struct bundle_header *header,
-	     int bundle_fd, int flags);
+	     int bundle_fd, struct strvec *extra_index_pack_args);
 int list_bundle_refs(struct bundle_header *header,
 		int argc, const char **argv);
 
diff --git a/transport.c b/transport.c
index 17e9629710a..8bc4b5fcd3c 100644
--- a/transport.c
+++ b/transport.c
@@ -162,12 +162,15 @@ static int fetch_refs_from_bundle(struct transport *transport,
 			       int nr_heads, struct ref **to_fetch)
 {
 	struct bundle_transport_data *data = transport->data;
+	struct strvec extra_index_pack_args = STRVEC_INIT;
 	int ret;
 
+	strvec_push(&extra_index_pack_args, "-v");
+
 	if (!data->get_refs_from_bundle_called)
 		get_refs_from_bundle(transport, 0, NULL);
 	ret = unbundle(the_repository, &data->header, data->fd,
-			   transport->progress ? BUNDLE_VERBOSE : 0);
Previously, this was conditioned on 'transport->progress', but above
you unconditionally add the "-v" option. Seems like a bug.
Yes! Oops. Will fix. Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help