From: Patrick Steinhardt <ps@pks.im>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 5/5] bundle: generate packfiles via the object database
Date: Fri, 14 Aug 2026 09:40:49 +0200 [thread overview]
Message-ID: <an7GgQLQfleCPr-a@pks.im> (raw)
In-Reply-To: <xmqqmrupsxx9.fsf@gitster.g>
On Thu, Aug 13, 2026 at 11:00:34AM -0700, Junio C Hamano wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > diff --git a/bundle.c b/bundle.c
> > index b64716f252..09afc465c0 100644
> > --- a/bundle.c
> > +++ b/bundle.c
> > @@ -325,50 +325,52 @@ static int is_tag_in_date_range(struct object *tag, struct rev_info *revs)
> >
> >
> > /* Write the pack data to bundle_fd */
> > -static int write_pack_data(int bundle_fd, struct rev_info *revs, struct strvec *pack_options)
> > +static int write_pack_data(int bundle_fd, struct rev_info *revs, int progress)
> > {
> > - struct child_process pack_objects = CHILD_PROCESS_INIT;
> > + struct odb_generate_pack_options opts = ODB_GENERATE_PACK_OPTIONS_INIT;
> > + struct odb_pack_generator *generator;
> > + int ret = 0;
> > int i;
> >
> > - strvec_pushl(&pack_objects.args,
> > - "pack-objects",
> > - "--stdout", "--thin", "--delta-base-offset",
> > - NULL);
> > - strvec_pushv(&pack_objects.args, pack_options->v);
> > + opts.thin = 1;
> > + opts.ofs_delta = 1;
> > + if (progress)
> > + opts.progress = ODB_GENERATE_PACK_PROGRESS_VERBOSE;
> > if (revs->filter.choice)
> > - strvec_pushf(&pack_objects.args, "--filter=%s",
> > - list_objects_filter_spec(&revs->filter));
> > - pack_objects.in = -1;
> > - pack_objects.out = bundle_fd;
> > - pack_objects.git_cmd = 1;
> > + opts.filter_spec = list_objects_filter_spec(&revs->filter);
> >
> > /*
> > - * start_command() will close our descriptor if it's >1. Duplicate it
> > - * to avoid surprising the caller.
> > + * The pack generator will consume our descriptor if it's >1.
> > + * Duplicate it to avoid surprising the caller.
> > */
> > - if (pack_objects.out > 1) {
> > - pack_objects.out = dup(pack_objects.out);
> > - if (pack_objects.out < 0) {
> > - error_errno(_("unable to dup bundle descriptor"));
> > - child_process_clear(&pack_objects);
> > - return -1;
> > - }
> > + opts.pack_fd = bundle_fd;
> > + if (opts.pack_fd > 1) {
> > + opts.pack_fd = dup(bundle_fd);
> > + if (opts.pack_fd < 0)
> > + return error_errno(_("unable to dup bundle descriptor"));
> > }
> >
> > - if (start_command(&pack_objects))
> > - return error(_("Could not spawn pack-objects"));
> > -
> > for (i = 0; i < revs->pending.nr; i++) {
> > struct object *object = revs->pending.objects[i].item;
> > if (object->flags & UNINTERESTING)
> > - write_or_die(pack_objects.in, "^", 1);
> > - write_or_die(pack_objects.in, oid_to_hex(&object->oid), the_hash_algo->hexsz);
> > - write_or_die(pack_objects.in, "\n", 1);
> > + oid_array_append(&opts.haves, &object->oid);
> > + else
> > + oid_array_append(&opts.wants, &object->oid);
> > }
> > - close(pack_objects.in);
> > - if (finish_command(&pack_objects))
> > - return error(_("pack-objects died"));
> > - return 0;
> > +
> > + if (odb_generate_pack(the_repository->objects, &generator, &opts)) {
> > + ret = error(_("Could not spawn pack-objects"));
> > + goto out;
> > + }
> > +
> > + if (odb_pack_generator_finish(generator)) {
> > + ret = error(_("pack-objects died"));
> > + goto out;
> > + }
> > +
> > +out:
> > + odb_generate_pack_options_release(&opts);
> > + return ret;
> > }
>
> This function uses the_repository, both directly and through
> the_hash_algo macro. I think we could use revs->repo here. An
> obvious alternative is to give this function a new parameter "struct
> repository *repo" but then we would have to worry about what should
> happen when it and revs->repo go out of sync.
Fair enough.
Ideally, we'd convert the whole file to not use `the_repository` at all
anymore. But we unfortunately call `get_log_output_encoding()`, which
implicitly depends on that function. I think we can still mostly drop
the dependency and then just add an `extern` declaration. I'll do so in
the next version.
Thanks!
Patrick
next prev parent reply other threads:[~2026-08-14 7:40 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 10:45 [PATCH 0/5] odb: make packfile generation pluggable Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 1/5] odb: introduce interface to generate packfiles Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 2/5] upload-pack: generate packfiles via the object database Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 3/5] send-pack: " Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 4/5] builtin/bundle: refactor option handling for progress meter Patrick Steinhardt
2026-08-07 10:45 ` [PATCH 5/5] bundle: generate packfiles via the object database Patrick Steinhardt
2026-08-13 18:00 ` Junio C Hamano
2026-08-14 7:40 ` Patrick Steinhardt [this message]
2026-08-07 21:05 ` [PATCH 0/5] odb: make packfile generation pluggable Junio C Hamano
2026-08-10 5:25 ` Patrick Steinhardt
2026-08-12 23:41 ` Taylor Blau
2026-08-13 5:47 ` Patrick Steinhardt
2026-08-13 17:35 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=an7GgQLQfleCPr-a@pks.im \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.