From: Teng Long <dyroneteng@gmail.com> To: git@vger.kernel.org Cc: avarab@gmail.com, me@ttaylorr.com, derrickstolee@github.com, tenglong.tl@alibaba-inc.com, Teng Long <dyroneteng@gmail.com> Subject: [PATCH v1 0/3] trace2 output for bitmap decision path Date: Thu, 24 Mar 2022 19:43:58 +0800 [thread overview] Message-ID: <cover.1648119652.git.dyroneteng@gmail.com> (raw) A Git repo can be chosen to use the normal bitmap (before MIDX) and MIDX bitmap. I recently tried to understand this part of the MIDX implementation because I found a bug which has been discovered and repaired in community [1]. I am grateful to Taylor Blau for his help and for introducing me to the testing method according to the `git rev-list --test-bitmap <rev>`. In the process of understanding and troubleshooting by using this command, I found when the execution is failed it will output a single line of "fatal: failed to load bitmap indexes", sometimes will be more informations like if the bitmap file is broken, the outputs maybe contain "error: Corrupted bitmap index file (wrong header)".), but most of time are single line output I mentioned above. So, this brings a little obstacle for debugging and troubleshooting I think, because "failed to load bitmap indexes" can represent to much informations (many causes like: midx config turn off, bitmap inexistence, etc.) Therefore, as a git repo can be chosen to use the normal bitmap (before MIDX) or MIDX bitmap, or they can both exist and let git make the decision. I think why not add some extra informations based on TRACE2 to help for showing the bitmap decision path clearer and more plentiful, so when the failure occurs the user can use it to debug around bitmap in a quicker way. Thanks. Links: 1. https://public-inbox.org/git/cover.1638991570.git.me@ttaylorr.com/) Teng Long (3): pack-bitmap.c: use "ret" in "open_midx_bitmap()" pack-bitmap.c: add "break" statement in "open_pack_bitmap()" bitmap: add trace outputs during open "bitmap" file midx.c | 2 ++ pack-bitmap.c | 17 +++++++++++++---- 2 files changed, 15 insertions(+), 4 deletions(-) Range-diff against v0: -: ---------- > 1: 3048b4dd29 pack-bitmap.c: use "ret" in "open_midx_bitmap()" -: ---------- > 2: 70500b6343 pack-bitmap.c: add "break" statement in "open_pack_bitmap()" -: ---------- > 3: 9912450fc1 bitmap: add trace outputs during open "bitmap" file -- 2.35.1.579.g70500b6343.dirty
next reply other threads:[~2022-03-24 11:44 UTC|newest] Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-24 11:43 Teng Long [this message] 2022-03-24 11:43 ` [PATCH v1 1/3] pack-bitmap.c: use "ret" in "open_midx_bitmap()" Teng Long 2022-03-24 19:11 ` Taylor Blau 2022-03-28 7:59 ` [PATCH v1 1/3] pack-bitmap.c: use "ret" in "open_midx_bitmap() Teng Long 2022-03-30 2:39 ` Taylor Blau 2022-03-24 11:44 ` [PATCH v1 2/3] pack-bitmap.c: add "break" statement in "open_pack_bitmap()" Teng Long 2022-03-24 18:40 ` Junio C Hamano 2022-03-24 19:06 ` Taylor Blau 2022-03-24 19:03 ` Taylor Blau 2022-03-29 2:49 ` Teng Long 2022-03-30 2:55 ` Taylor Blau 2022-03-30 7:32 ` Teng Long Teng Long 2022-03-30 13:17 ` Ævar Arnfjörð Bjarmason 2022-03-24 11:44 ` [PATCH v1 3/3] bitmap: add trace outputs during open "bitmap" file Teng Long 2022-03-24 18:42 ` Junio C Hamano 2022-03-24 13:22 ` [PATCH v1 0/3] trace2 output for bitmap decision path Ævar Arnfjörð Bjarmason 2022-03-29 7:38 ` Teng Long Teng Long 2022-03-29 8:54 ` Ævar Arnfjörð Bjarmason 2022-04-21 13:26 ` [PATCH v2 0/5] trace2 output for bitmap decision path Teng Long 2022-04-21 13:26 ` [PATCH v2 1/5] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long 2022-05-11 21:31 ` Taylor Blau 2022-04-21 13:26 ` [PATCH v2 2/5] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long 2022-05-11 21:31 ` Taylor Blau 2022-04-21 13:26 ` [PATCH v2 3/5] pack-bitmap.c: make warnings more detailed when opening bitmap Teng Long 2022-04-21 17:25 ` Taylor Blau 2022-05-06 9:08 ` Teng Long 2022-04-21 13:26 ` [PATCH v2 4/5] bitmap: add trace2 outputs during open "bitmap" file Teng Long 2022-04-21 15:51 ` Ævar Arnfjörð Bjarmason 2022-05-06 11:27 ` Teng Long 2022-05-06 11:53 ` Teng Long 2022-04-21 16:32 ` Jeff Hostetler 2022-05-06 12:43 ` Teng Long 2022-05-10 20:47 ` Jeff Hostetler 2022-04-21 13:26 ` [PATCH v2 5/5] pack-bitmap.c: using error() instead of silently returning -1 Teng Long 2022-04-21 15:41 ` Ævar Arnfjörð Bjarmason 2022-05-06 12:55 ` Teng Long 2022-06-12 7:44 ` [PATCH v3 0/5] Teng Long 2022-06-12 7:44 ` [PATCH v3 1/5] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long 2022-06-12 7:44 ` [PATCH v3 2/5] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long 2022-06-12 7:44 ` [PATCH v3 3/5] pack-bitmap.c: make warnings support i18N when opening bitmap Teng Long 2022-06-12 7:44 ` [PATCH v3 4/5] pack-bitmap.c: using error() instead of silently returning -1 Teng Long 2022-06-14 1:15 ` Taylor Blau 2022-06-20 13:17 ` Teng Long 2022-06-12 7:44 ` [PATCH v3 5/5] bitmap: add trace2 outputs during open "bitmap" file Teng Long 2022-06-13 20:59 ` Junio C Hamano 2022-06-20 13:32 ` Teng Long 2022-06-14 1:40 ` Taylor Blau 2022-06-21 6:58 ` Teng Long 2022-06-22 12:51 ` Jeff Hostetler 2022-06-23 9:38 ` Teng Long 2022-06-23 15:14 ` Jeff Hostetler 2022-06-24 8:27 ` [PATCH v3 5/5] bitmap: add trace2 outputs during open "bitmap" Teng Long 2022-06-21 13:25 ` [PATCH v3 0/5] trace2 output for bitmap decision path Teng Long 2022-06-21 13:25 ` [PATCH v3 1/5] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long 2022-06-21 13:25 ` [PATCH v3 2/5] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long 2022-06-21 13:25 ` [PATCH v3 3/5] pack-bitmap.c: make warnings support i18N when opening bitmap Teng Long 2022-06-21 13:25 ` [PATCH v3 4/5] pack-bitmap.c: using error() instead of silently returning -1 Teng Long 2022-06-21 13:25 ` [PATCH v3 5/5] bitmap: add trace2 outputs during open "bitmap" file Teng Long 2022-06-22 13:04 ` Jeff Hostetler 2022-06-22 15:12 ` 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 List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=cover.1648119652.git.dyroneteng@gmail.com \ --to=dyroneteng@gmail.com \ --cc=avarab@gmail.com \ --cc=derrickstolee@github.com \ --cc=git@vger.kernel.org \ --cc=me@ttaylorr.com \ --cc=tenglong.tl@alibaba-inc.com \ --subject='Re: [PATCH v1 0/3] trace2 output for bitmap decision path' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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 read-only IMAP folder(s) and NNTP newsgroup(s).