The documentation for --use-bitmap-index notes that if used with --objects trees and blobs they won't have their paths printed, but it appears to change a whole lot more than that. In my testing, it appears to mean --date-order, --format. --parents, and maybe more are effectively ignored. It appears this changed in 2.26.0. The release notes for that version include this blurb, which seems like it might be relevant, but I'm not sure: * The object reachability bitmap machinery and the partial cloning machinery were not prepared to work well together, because some object-filtering criteria that partial clones use inherently rely on object traversal, but the bitmap machinery is an optimization to bypass that object traversal. There however are some cases where they can work together, and they were taught about them. I have a repository with a bitmap: $ git repack -abdfln --keep-unreachable Marked 2 islands, done. Enumerating objects: 3603142, done. Propagating island marks: 100% (2576295/2576295), done. Counting objects: 100% (3603142/3603142), done. Delta compression using up to 20 threads Compressing objects: 100% (2898179/2898179), done. Writing objects: 100% (3603142/3603142), done. Reusing bitmaps: 291, done. Selecting bitmap commits: 293052, done. Building bitmaps: 100% (363/363), done. Here's some output from Git 2.25.1: $ /opt/git/2.25.1/bin/git rev-list --boundary --ignore-missing --date-order --parents --use-bitmap-index c6abb83d2798415fa9fe0ebd683623620076b412 1c55e675a66cb98955232e1bd230119fd97a5467 634396036782682e7cd8c955070dfb30546ed58c -- | head c6abb83d2798415fa9fe0ebd683623620076b412 2c7281b151d0079acc3f9b2c67d4667e1c9bf6d9 634396036782682e7cd8c955070dfb30546ed58c 1c55e675a66cb98955232e1bd230119fd97a5467 2c7281b151d0079acc3f9b2c67d4667e1c9bf6d9 d672894d3b2413b62034cb3cdb3470e5dee0001c 76250ec85aadff2ff451ec13efdadb8ccfd6b239 d672894d3b2413b62034cb3cdb3470e5dee0001c 013343e1900330429bcd1e31bb2ae7261fc1e3af 3e1e27621aa5f1d49286e23d77199004a835699e 3e1e27621aa5f1d49286e23d77199004a835699e b944291d204cb7f3d5eb7678360b16435c53b2f3 b745a7b9bd9434eefb411d5f2a80a7187e3e8b93 1c55e675a66cb98955232e1bd230119fd97a5467 7f2c871e0d239e87bef7a1505ae928ae3a09a402 76250ec85aadff2ff451ec13efdadb8ccfd6b239 04f561866a9c015c14c69a0294b753ced5e084f2 013343e1900330429bcd1e31bb2ae7261fc1e3af d907528818d010a360113790e227ebbcd8a61395 b745a7b9bd9434eefb411d5f2a80a7187e3e8b93 b944291d204cb7f3d5eb7678360b16435c53b2f3 7f2c871e0d239e87bef7a1505ae928ae3a09a402 c2ec4d3d76d865a9b701eb8be822d31252278a76 Changing to Git 2.26.0, I see this: $ /opt/git/2.26.0/bin/git rev-list --boundary --ignore-missing --date-order --parents --use-bitmap-index c6abb83d2798415fa9fe0ebd683623620076b412 1c55e675a66cb98955232e1bd230119fd97a5467 634396036782682e7cd8c955070dfb30546ed58c -- | head 634396036782682e7cd8c955070dfb30546ed58c 1c55e675a66cb98955232e1bd230119fd97a5467 7f2c871e0d239e87bef7a1505ae928ae3a09a402 c2ec4d3d76d865a9b701eb8be822d31252278a76 899053a9043045fcfeb7f9254f2700d286c60a63 f1adcf64a8c06cb12f4e3e876040ee596fb3c0ca 16792db59ffdbbefe4a27a11a9831eac39be69a0 b844c3d11d09c2aec3428ce61bef02fdd097b9f9 802918fb139ef96cae5259822d22a36478c5e7b1 3a6105686ab302093648733dbf5fada3b44db72b No parents now, and the commits aren't in the same order. I've tested with 2.30.1 and it produces the same output as 2.26.0. If I remove the bitmap, all versions produce the same output as 2.25.1 does, with parents and in the expected order. (I should note, the bitmap is perfectly up-to-date; I did the repack right before running these rev-list commands. I've also tried the rev-list without several of the options in place, like --boundary, and it behaves the same. This command line is assembled automatically, so I'm just including it here how the system produced it.) Is this expected? If so, perhaps the --use-bitmap-index documentation should be updated to indicate that it has unexpected interactions with a whole lot more than just --objects? Or perhaps I'm doing something wrong/unexpected here? What sorts of traversals are --use-bitmap-index expected to be used for? Best regards, Bryan Turner
