From: Jeff King <peff@peff.net>
To: Doug Kelly <dougk.ff7@gmail.com>
Cc: git@vger.kernel.org, sbeller@google.com, gitster@pobox.com
Subject: Re: [PATCH 1/3] prepare_packed_git(): find more garbage
Date: Tue, 15 Dec 2015 18:09:57 -0500 [thread overview]
Message-ID: <20151215230957.GA30353@sigill.intra.peff.net> (raw)
In-Reply-To: <1448518529-2659-1-git-send-email-dougk.ff7@gmail.com>
On Thu, Nov 26, 2015 at 12:15:29AM -0600, Doug Kelly wrote:
> diff --git a/builtin/count-objects.c b/builtin/count-objects.c
> index ba92919..5197b57 100644
> --- a/builtin/count-objects.c
> +++ b/builtin/count-objects.c
> @@ -17,19 +17,15 @@ static off_t loose_size;
>
> static const char *bits_to_msg(unsigned seen_bits)
> {
> - switch (seen_bits) {
> - case 0:
> - return "no corresponding .idx or .pack";
> - case PACKDIR_FILE_GARBAGE:
> + if (seen_bits == PACKDIR_FILE_GARBAGE)
> return "garbage found";
It seems weird to use "==" on a bitfield. I think it is the case now
that we would never see GARBAGE alongside anything else, but I wonder if
we should future-proof that as:
if (seen_bits & PACKDIR_FILE_GARBAGE)
Specifically, I am wondering what would happen if we had "foo.pack" and
"foo.bogus", where we do not know about the latter at all.
> - case PACKDIR_FILE_PACK:
> + else if (seen_bits & PACKDIR_FILE_PACK && !(seen_bits & PACKDIR_FILE_IDX))
> return "no corresponding .idx";
> - case PACKDIR_FILE_IDX:
> + else if (seen_bits & PACKDIR_FILE_IDX && !(seen_bits & PACKDIR_FILE_PACK))
> return "no corresponding .pack";
> - case PACKDIR_FILE_PACK|PACKDIR_FILE_IDX:
> - default:
> - return NULL;
> - }
> + else if (seen_bits == 0 || !(seen_bits & (PACKDIR_FILE_IDX|PACKDIR_FILE_PACK)))
> + return "no corresponding .idx or .pack";
> + return NULL;
This bottom conditional is interesting. I understand the second half: we
saw something pack-like, but there is not matching .idx or .pack at all
(if we saw one but not the other, we would have caught it above).
But when will we get an empty seen_bits? What did we see that triggered
this function, but didn't trigger a bit (even GARBAGE)?
I don't mind if the answer is "nothing, this is future-proofing", but am
mostly curious.
> diff --git a/sha1_file.c b/sha1_file.c
> index 3d56746..5f939e4 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1225,6 +1225,15 @@ static void report_helper(const struct string_list *list,
> if (seen_bits == (PACKDIR_FILE_PACK|PACKDIR_FILE_IDX))
> return;
>
> + if (seen_bits == (PACKDIR_FILE_PACK|PACKDIR_FILE_IDX|PACKDIR_FILE_BITMAP))
> + return;
> +
> + if (seen_bits == (PACKDIR_FILE_PACK|PACKDIR_FILE_IDX|PACKDIR_FILE_KEEP))
> + return;
> +
> + if (seen_bits == (PACKDIR_FILE_PACK|PACKDIR_FILE_IDX|PACKDIR_FILE_BITMAP|PACKDIR_FILE_KEEP))
> + return;
> +
It seems like we're enumerating a lot of cases here that will explode if
we get even one more file type (e.g., we add "pack-XXX.foo" in the
future). If I understand this function correctly, we're just trying to
get rid of "boring" cases that do not need to be reported.
Isn't any case that has both a pack and an idx boring (no matter if it
has a .bitmap or .keep)?
IOW, can these four conditionals just become:
unsigned pack_with_idx = PACKDIR_FILE_PACK | PACKDIR_FILE_IDX;
if ((seen_bits & pack_with_idx) == pack_with_idx)
return;
?
-Peff
next prev parent reply other threads:[~2015-12-15 23:10 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-14 0:10 [PATCH 0/3] Add cleanup for garbage .bitmap files Doug Kelly
2015-11-14 0:10 ` [PATCH 1/3] prepare_packed_git(): find more garbage Doug Kelly
2015-11-14 0:43 ` Stefan Beller
2015-11-14 0:46 ` Doug Kelly
2015-11-14 0:46 ` [PATCH 2/3] t5304: Add test for .bitmap garbage files Doug Kelly
2015-11-14 0:46 ` [PATCH 3/3] gc: Clean garbage .bitmap files from pack dir Doug Kelly
2015-12-15 23:23 ` Jeff King
2015-11-25 18:43 ` [PATCH 1/3] prepare_packed_git(): find more garbage Stefan Beller
2015-11-26 6:15 ` Doug Kelly
2015-12-15 23:09 ` Jeff King [this message]
2015-12-15 23:25 ` Jeff King
2015-12-19 0:06 ` [PATCH v3 0/3] " Doug Kelly
2015-12-19 0:06 ` [PATCH 1/3] " Doug Kelly
2015-12-19 0:06 ` [PATCH 2/3] t5304: Add test for .bitmap garbage files Doug Kelly
2015-12-19 0:06 ` [PATCH 3/3] gc: Clean garbage .bitmap files from pack dir Doug Kelly
2015-12-19 2:01 ` Jeff King
2015-12-19 2:02 ` [PATCH v3 0/3] prepare_packed_git(): find more garbage Jeff King
2015-12-19 2:03 ` Jeff King
2016-01-11 16:35 ` Stefan Beller
2016-01-13 17:07 ` [PATCH v4 0/4] gc: Clean garbage .bitmap files from pack dir Doug Kelly
2016-01-13 17:07 ` [PATCH 1/4] prepare_packed_git(): find more garbage Doug Kelly
2016-01-13 17:07 ` [PATCH 2/4] t5304: Add test for .bitmap garbage files Doug Kelly
2016-01-13 20:42 ` Junio C Hamano
2016-01-13 17:07 ` [PATCH 3/4] t5304: Ensure wanted files are not deleted Doug Kelly
2016-01-13 20:55 ` Junio C Hamano
2016-01-18 16:54 ` Doug Kelly
2016-01-19 18:36 ` Junio C Hamano
2016-01-13 17:07 ` [PATCH 4/4] gc: Clean garbage .bitmap files from pack dir Doug Kelly
2015-11-26 6:18 ` [PATCH 1/3] prepare_packed_git(): find more garbage Doug Kelly
2015-11-14 0:47 ` Doug Kelly
2015-11-14 0:10 ` [PATCH 2/3] t5304: Add test for .bitmap garbage files Doug Kelly
2015-11-14 0:47 ` Stefan Beller
2015-11-14 0:10 ` [PATCH 3/3] gc: Clean garbage .bitmap files from pack dir Doug Kelly
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=20151215230957.GA30353@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=dougk.ff7@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=sbeller@google.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).