From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] repack: add config to skip updating server info
Date: Mon, 14 Mar 2022 08:19:23 +0100 [thread overview]
Message-ID: <Yi7se2c03E4PNnsX@ncase> (raw)
In-Reply-To: <Yit22Xcs6iF4MVB7@nand.local>
[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]
On Fri, Mar 11, 2022 at 11:20:41AM -0500, Taylor Blau wrote:
> On Fri, Mar 11, 2022 at 12:09:30PM +0100, Patrick Steinhardt wrote:
> > diff --git a/Documentation/config/repack.txt b/Documentation/config/repack.txt
> > index 9c413e177e..22bfc26afc 100644
> > --- a/Documentation/config/repack.txt
> > +++ b/Documentation/config/repack.txt
> > @@ -25,3 +25,6 @@ repack.writeBitmaps::
> > space and extra time spent on the initial repack. This has
> > no effect if multiple packfiles are created.
> > Defaults to true on bare repos, false otherwise.
> > +
> > +repack.updateServerInfo::
> > + If set to false, git-repack will not run git-update-server-info.
>
> Can you clarify here what the default value of this config variable is,
> and how it interacts with repack's `-n` flag? E.g., something along the
> lines of:
>
> repack.updateServerInfo::
> If set to false, linkgit:git-repack[1] will not run
> linkgit:git-update-serve-info[1]. Defaults to true. Can be
> overridden when true by the `-n` option of
> linkgit:git-repack[1].
>
> Perhaps a little verbose, but I think it leaves less ambiguity about
> what this new configuration variable is for.
Makes sense.
> > diff --git a/builtin/repack.c b/builtin/repack.c
> > index da1e364a75..3baa993da2 100644
> > --- a/builtin/repack.c
> > +++ b/builtin/repack.c
> > @@ -22,6 +22,7 @@ static int delta_base_offset = 1;
> > static int pack_kept_objects = -1;
> > static int write_bitmaps = -1;
> > static int use_delta_islands;
> > +static int no_update_server_info = 0;
>
> Not the fault of this patch, but I wonder if this would be less
> confusing if we stored `update_server_info` instead of
> `no_update_server_info`. If you have time, I think it may be worth a
> preparatory patch at the beginning to swap the two.
[snip]
I indeed first had a look at how to do this, but didn't find a negated
`OPT_BOOL()`. I had another look now though, and it seems like this is
typically solved via `OPT_NEGBIT()`.
Thanks!
Patrick
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-03-14 7:19 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-11 11:09 [PATCH] repack: add config to skip updating server info Patrick Steinhardt
2022-03-11 16:20 ` Taylor Blau
2022-03-14 7:19 ` Patrick Steinhardt [this message]
2022-03-14 7:42 ` [PATCH v2 0/2] " Patrick Steinhardt
2022-03-14 7:42 ` [PATCH v2 1/2] repack: refactor to avoid double-negation of update-server-info Patrick Steinhardt
2022-03-14 7:42 ` [PATCH v2 2/2] repack: add config to skip updating server info Patrick Steinhardt
2022-03-14 22:26 ` 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=Yi7se2c03E4PNnsX@ncase \
--to=ps@pks.im \
--cc=git@vger.kernel.org \
--cc=me@ttaylorr.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.