Re: [PATCH v1 0/8] repo_config_values: migrate more globals
- From
Bello Olamide <belkid98@gmail.com>
- Date
- Mar 12, 2026, 13:18 UTC
- Message-ID
- <CAD=f0L9V14gdTgYzQ6aXqq9U8vmi-BozhmHAPVCaSR+2VYythw@mail.gmail.com>
- In-Reply-To
- <9f9a2e8e-6db7-4105-ba2b-7e42bff2ad1a@gmail.com>
On Thu, 12 Mar 2026 at 06:03, Tian Yuchen <a3205153416@gmail.com> wrote:
Show 70 quoted lines
>
> Hi Olamide,
>
> On 3/10/26 20:06, Olamide Caleb Bello wrote:
> > int status = Z_OK;
> > int write_object = (flags & INDEX_WRITE_OBJECT);
> > off_t offset = 0;
> > + struct repo_config_values *cfg = repo_config_values(the_repository);
> >
> > - git_deflate_init(&s, pack_compression_level);
> > + git_deflate_init(&s, cfg->pack_compression_level);
> >
> > hdrlen = encode_in_pack_object_header(obuf, sizeof(obuf), OBJ_BLOB, size);
> > s.next_out = obuf + hdrlen;
>
> I didn't look closely at the other parts, but I have a small question
> about this section.
>
> pack_compression_level before this patch is a global variable:
>
> int pack_compression_level = Z_DEFAULT_COMPRESSION;
>
> and struct option in cmd_pack_objects contains its pointer:
>
> struct option pack_objects_options[] = {
> ...
> OPT_INTEGER(0, "compression", &pack_compression_level, ...),
> ...
> };
>
> The reason why functions such as do_compress, write_large_blob_data can
> work properly is beacuse they all read the same global variable, right?
>
>
> However, in this patch,
>
> > + struct repo_config_values *cfg = repo_config_values(the_repository);
> > + int pack_compression_level = cfg->pack_compression_level;
>
> Here, a local variable with the same name was created via value
> assignment (I also find the naming a bit odd).
>
> > @@ -383,8 +383,9 @@ static unsigned long do_compress(void **pptr, unsigned long size)
> > git_zstream stream;
> > void *in, *out;
> > unsigned long maxsize;
> > + struct repo_config_values *cfg = repo_config_values(the_repository);
> >
> > - git_deflate_init(&stream, pack_compression_level);
> > + git_deflate_init(&stream, cfg->pack_compression_level);
> > maxsize = git_deflate_bound(&stream, size);
>
> But then in the do_compress() function, the variable being read is still
> that pointer, cfg->pack_compression_level. The expected input wasn't
> *written back* to this pointer, right? If I understand correctly, after
> parsing CLI, the output is written to the local variable rather than the
> cfg. And that's why the naming is a bit confusing to me.
>
> struct option pack_objects_options[] = {
> ...
> OPT_INTEGER(0, "compression", &cfg->pack_compression_level, ...),
> ...
> };
>
> I think change like this is needed. Of course, you'll need to
> double-check it. _(:3 」∠ )_
>
> Regards,
>
> YuchenHi Yuchen,
Thanks for taking a close look.
My intention here was mainly to avoid repeating `cfg->pack_compression_level` multiple times in the function, so I introduced a local `pack_compression_level` initialized from `cfg->pack_compression_level`.
But you are right to point out the interaction with the CLI option. The --compression option currently writes to the local variable via OPT_INTEGER, and the value is not propagated back to `cfg->pack_compression_level`.
I took a second look at it and will change the option to write directly into `cfg->pack_compression_level instead` in upcoming versions.
Thanks for pointing this out.
Best regards, Olamide Caleb Bello