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@xxxxxxxxxxxx/) 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
