Teng Long
- From
Teng Long <dyroneteng@gmail.com>
- Date
- Mar 30, 2022, 07:32 UTC
- Message-ID
- <20220330073230.61358-1-dyroneteng@gmail.com>
- In-Reply-To
- <YkPGq0mDL4NG6D1o@nand.local>
On Tue, 29 Mar 2022 22:55:39 -0400, Taylor Blau wrote:
Show 30 quoted lines
> You're right; open_pack_bitmap_1() doesn't need to care about whether or
> not bitmap_git->midx is or isn't non-NULL, since:
>
> - if we did open a MIDX bitmap (which we will always attempt first
> before trying to open single-pack bitmaps), then we won't even
> bother to call open_pack_bitmap() at all.
>
> - if we _do_ end up within open_pack_bitmap_1(), then we _know_ that
> no MIDX bitmap could be found/opened, so there is no need to check
> in that case, either.
>
> So I think we realistically could do something like:
>
> --- 8< ---
>
> diff --git a/pack-bitmap.c b/pack-bitmap.c
> index 97909d48da..6e7c89826d 100644
> --- a/pack-bitmap.c
> +++ b/pack-bitmap.c
> @@ -387,3 +387,3 @@ static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git
>
> - if (bitmap_git->pack || bitmap_git->midx) {
> + if (bitmap_git->pack) {
> /* ignore extra bitmap file; we can only handle one */
>
> --- >8 ---
> ...but having the conditional there from the pre-image doesn't hurt,
> either, and it makes the error clearer in case of an accidental
> regression where we start looking for single-pack bitmaps after
> successfully opening a multi-pack one.I agree with the "accidental regression", it's a protection without any disadvantages so far. So, if we don't remove the "bitmap_git->midx" condition for some robust reason, then I think maybe we can let the warning more detailed if the "accident" happens, like:
diff --git a/pack-bitmap.c b/pack-bitmap.c index 91a6be358d..e64a85bc59 100644 --- a/pack-bitmap.c +++ b/pack-bitmap.c @@ -333,7 +333,15 @@ static int open_midx_bitmap_1(struct bitmap_index *bitmap_git, struct strbuf buf = STRBUF_INIT; get_midx_filename(&buf, midx->object_dir); /* ignore extra bitmap file; we can only handle one */ - warning("ignoring extra bitmap file: %s", buf.buf); + warning("%signoring extra bitmap file: %s", + bitmap_git->pack ? + xstrfmt("A non-MIDX bitmap has been opened: %s, ", + bitmap_git->pack->pack_name) : + bitmap_git->midx ? + xstrfmt("A MIDX bitmap has been opened : %s, ", + midx_bitmap_filename(bitmap_git->midx)) : + "", + buf.buf); close(fd); strbuf_release(&buf); return -1; @@ -398,9 +406,17 @@ static int open_pack_bitmap_1(struct bitmap_index *bitmap_git, struct packed_git return -1; } - if (bitmap_git->pack) { + if (bitmap_git->pack || bitmap_git->midx) { /* ignore extra bitmap file; we can only handle one */ - warning("ignoring extra bitmap file: %s", packfile->pack_name); + warning("%signoring extra bitmap file: %s", + bitmap_git->pack ? + xstrfmt("A non-MIDX bitmap has been opened: %s, ", + bitmap_git->pack->pack_name) : + bitmap_git->midx ? + xstrfmt("A MIDX bitmap has been opened : %s, ", + midx_bitmap_filename(bitmap_git->midx)) : + "", + packfile->pack_name); close(fd); return -1; } diff --git a/t/t5310-pack-bitmaps.sh b/t/t5310-pack-bitmaps.sh index f775fc1ce6..a962f6861f 100755 --- a/t/t5310-pack-bitmaps.sh +++ b/t/t5310-pack-bitmaps.sh @@ -421,6 +421,7 @@ test_expect_success 'complains about multiple pack bitmaps' ' test_line_count = 2 bitmaps && git rev-list --use-bitmap-index HEAD 2>err && + grep "A non-MIDX bitmap has been opened" err && grep "ignoring extra bitmap file" err ) Does that make sense to you? And also I look codes in "open_midx_bitmap_1()", it's really nice for me to read and understand, but the "char *idx_name = ..." declaration made me a litte confusing at the beginning, I think maybe it's better to name it as "bitmap_name" for it, I know bitmap is also a kind of index structure for using, but when I saw "idx", it brings me to the ".idx" or "multi-pack-index" like files naturally in git context, of course this is not a problem and maybe it's just me.