git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Gregory Szorc" <gregory.szorc@gmail.com>,
	"Eric Wong" <e@80x24.org>,
	git@vger.kernel.org
Subject: Re: [PATCH 2/3] repack: silence warnings when auto-enabled bitmaps cannot be built
Date: Wed, 31 Jul 2019 17:11:44 -0400	[thread overview]
Message-ID: <20190731211144.GA1207@sigill.intra.peff.net> (raw)
In-Reply-To: <xmqqftmmosrf.fsf@gitster-ct.c.googlers.com>

On Wed, Jul 31, 2019 at 01:26:12PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > @@ -3313,8 +3319,13 @@ int cmd_pack_objects(int argc, const char **argv, const char *prefix)
> >  			    N_("do not hide commits by grafts"), 0),
> >  		OPT_BOOL(0, "use-bitmap-index", &use_bitmap_index,
> >  			 N_("use a bitmap index if available to speed up counting objects")),
> > -		OPT_BOOL(0, "write-bitmap-index", &write_bitmap_index,
> > -			 N_("write a bitmap index together with the pack index")),
> > +		OPT_SET_INT(0, "write-bitmap-index", &write_bitmap_index,
> > +			    N_("write a bitmap index together with the pack index"),
> > +			    WRITE_BITMAP_TRUE),
> > +		OPT_SET_INT_F(0, "write-bitmap-index-quiet",
> > +			      &write_bitmap_index,
> > +			      N_("write a bitmap index if possible"),
> > +			      WRITE_BITMAP_QUIET, PARSE_OPT_HIDDEN),
> 
> The receiving end of this communication is pretty easy to follow.
> I'd have named an option to trigger "if possible" behaviour after
> that "if possible" phrase and not "quiet", but this is entirely
> internal that it does not matter.

Heh, that was actually the part of this series that I struggled the most
with. I didn't like "if possible" because that is already how we behave
(we continue without bitmaps if we can't make them, even if the user
asked for them explicitly). I had "if convenient" at one point, but it
seemed too vague and too long. ;)

So I'm happy to change it, but it would require somebody coming up with
a better name.

> >  	if (write_bitmaps < 0) {
> > -		write_bitmaps = (pack_everything & ALL_INTO_ONE) &&
> > -				 is_bare_repository() &&
> > -				 keep_pack_list.nr == 0 &&
> > -				 !has_pack_keep_file();
> > +		if (!(pack_everything & ALL_INTO_ONE) ||
> > +		    !is_bare_repository() ||
> > +		    keep_pack_list.nr != 0 ||
> > +		    has_pack_keep_file())
> > +			write_bitmaps = 0;
> 
> This side of communication is a bit harder to follow, but not
> impossible ;-) We leave it "negative" to signal "the user did not
> specify, but we enabled it by default" here.

Yeah, I also noticed that was a bit subtle. Maybe a comment:

  /* leave as -1 to indicate "auto bitmaps" */

or something would help. I also thought about writing it as:

  if (write_bitmaps < 0) {
	if ((pack_everything & ALL_INTO_ONE) &&
	    is_bare_repository() &&
	    keep_pack_list.nr == 0 &&
	    !hash_pack_keep_file()) {
		write_bitmaps = -1; /* indicates auto-enabled */
	} else {
		write_bitmaps = 0;
	}
  }

Better?

-Peff

  reply	other threads:[~2019-07-31 21:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-26  2:18 Warnings in gc.log can prevent gc --auto from running Gregory Szorc
2019-07-29 10:07 ` Jeff King
2019-07-29 12:50   ` Ævar Arnfjörð Bjarmason
2019-07-31  4:28     ` Jeff King
2019-07-31  5:37       ` [PATCH 0/3] handling warnings due to auto-enabled bitmaps Jeff King
2019-07-31  5:37         ` [PATCH 1/3] t7700: clean up .keep file in bitmap-writing test Jeff King
2019-07-31  5:39         ` [PATCH 2/3] repack: silence warnings when auto-enabled bitmaps cannot be built Jeff King
2019-07-31 20:26           ` Junio C Hamano
2019-07-31 21:11             ` Jeff King [this message]
2019-07-31  5:40         ` [PATCH 3/3] repack: simplify handling of auto-bitmaps and .keep files Jeff King
2019-07-31 22:34           ` 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=20190731211144.GA1207@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=avarab@gmail.com \
    --cc=e@80x24.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=gregory.szorc@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).