Teng Long <dyroneteng@xxxxxxxxx> writes: > This patch tries to avoid the problem of leaking sensitive information that > could output the absolute path of the repository when try to open multiple > bitmaps. For example, in "alternates" scenario, where the repository > "alternate_repo" serves as alternate object stores for repository > "want_to_borrow" , and each of both has it's own bitmap file, then we run > `git rev-list --use-bitmap-index HEAD`, the output might be: > $ cd want_to_borrow.git > $ git rev-list --test-bitmap HEAD > warning: ignoring extra bitmap file: /Users/tenglong.tl/Downloads/alternate_repo.git/.git/objects/pack/pack-bff67e2a7a154e6933afe61b3681726cf9bd8e8b.pack > Bitmap v1 test (1 entries loaded) > Found bitmap for 30f146d41a7a86930fae3f4a5e1f1c1f2bfacbba. 64 bits / 11030517 checksum > Verifying bitmap entries: 100% (3/3), done. > OK! > > After apply this patch: > > $ git rev-list --test-bitmap HEAD > warning: ignoring extra bitmap files > Bitmap v1 test (1 entries loaded) > Found bitmap for 30f146d41a7a86930fae3f4a5e1f1c1f2bfacbba. 64 bits / 11030517 checksum > Verifying bitmap entries: 100% (3/3), done. > OK! I am not sure why it is an improvement though. Doesn't it make it harder to diagnose where the extra bitmap file you do not need exists (so that you can check if you can/want to/need to remove it)? If the "ignoring extra" is a totally expected situation (e.g. it is not suprising if we always ignore the bitmapfile in the alternate when we have our own), perhaps we should squelch the warning in such expected cases altogether (while warning other cases where we see more bitmap files than we expect to see, which may be an anomaly worth warning about), and that may be an improvement worth spending development cycles on, but I am not sure about this one.
