From: Stefan Beller <sbeller@google.com>
To: Derrick Stolee <dstolee@microsoft.com>
Cc: git <git@vger.kernel.org>
Subject: Re: [PATCH 3/9] midx: mark bad packed objects
Date: Mon, 20 Aug 2018 14:23:06 -0700 [thread overview]
Message-ID: <CAGZ79kY8i3y6_r=bQAx7V5=ckSmb_RgyByjJwtS+7Qr2y8x8LQ@mail.gmail.com> (raw)
In-Reply-To: <20180820165124.152146-4-dstolee@microsoft.com>
On Mon, Aug 20, 2018 at 9:52 AM Derrick Stolee <dstolee@microsoft.com> wrote:
>
> When an object fails to decompress from a pack-file, we mark the object
> as 'bad' so we can retry with a different copy of the object (if such a
> copy exists).
>
> Before now, the multi-pack-index did not update the bad objects list for
> the pack-files it contains, and we did not check the bad objects list
> when reading an object. Now, do both.
This sounds like a bug fix unlike patches 1 & 2 that sound like
feature work(2) or making code more readable(1).
(After studying the code, this doesn't sound like a bug fix any more,
but a safety thing)
Is it worth having this on a separate track coming in
faster than the rest of this series?
>
> Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
> ---
> midx.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/midx.c b/midx.c
> index 6824acf5f8..7fa75a37a3 100644
> --- a/midx.c
> +++ b/midx.c
> @@ -280,6 +280,16 @@ static int nth_midxed_pack_entry(struct multi_pack_index *m, struct pack_entry *
> if (!is_pack_valid(p))
> return 0;
>
> + if (p->num_bad_objects) {
> + uint32_t i;
Is there a reason that i needs to be if 32 bits?
Would size_t (for iterating) or 'int' (as a default
like in many for loops) be ok, too?
next prev parent reply other threads:[~2018-08-20 21:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-20 16:51 [PATCH 0/9] multi-pack-index cleanups Derrick Stolee
2018-08-20 16:51 ` [PATCH 1/9] multi-pack-index: provide more helpful usage info Derrick Stolee
2018-08-20 16:51 ` [PATCH 2/9] multi-pack-index: store local property Derrick Stolee
2018-08-20 21:14 ` Stefan Beller
2018-08-20 16:51 ` [PATCH 3/9] midx: mark bad packed objects Derrick Stolee
2018-08-20 21:23 ` Stefan Beller [this message]
2018-08-21 13:53 ` Derrick Stolee
2018-08-20 16:51 ` [PATCH 4/9] midx: stop reporting garbage Derrick Stolee
2018-08-20 16:52 ` [PATCH 5/9] midx: fix bug that skips midx with alternates Derrick Stolee
2018-08-20 16:52 ` [PATCH 6/9] packfile: add all_packs list Derrick Stolee
2018-08-20 16:52 ` [PATCH 7/9] treewide: use get_all_packs Derrick Stolee
2018-08-20 22:01 ` Stefan Beller
2018-08-21 13:56 ` Derrick Stolee
2018-08-20 16:52 ` [PATCH 8/9] midx: test a few commands that " Derrick Stolee
2018-08-20 22:03 ` Stefan Beller
2018-08-20 16:52 ` [PATCH 9/9] pack-objects: consider packs in multi-pack-index Derrick Stolee
2018-08-21 14:34 ` [PATCH 0/9] multi-pack-index cleanups Duy Nguyen
2018-08-21 14:44 ` Derrick Stolee
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='CAGZ79kY8i3y6_r=bQAx7V5=ckSmb_RgyByjJwtS+7Qr2y8x8LQ@mail.gmail.com' \
--to=sbeller@google.com \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
/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).