On 2/18/2020 3:05 PM, Jeff King wrote: > On Tue, Feb 18, 2020 at 01:18:21PM -0500, Derrick Stolee wrote: > >>> + test_expect_success "enumerate commits ($state)" ' >>> + git rev-list --use-bitmap-index HEAD >actual && >>> + git rev-list HEAD >expect && >>> + test_bitmap_traversal --no-confirm-bitmaps expect actual >>> + ' >>> + >> >> I was wondering if there is anything we could add to the "expect" >> command that could better guarantee these commits show up in a >> different order than the bitmap order, allowing us to drop the >> "--no-confirm-bitmaps". Perhaps the issue is the merge structure >> of the repository, and how it will cause these orders to always >> agree? >> >> I suppose "--topo-order" may actually present an order _even closer_ >> to the bitmap order. > > I think in the partial-bitmap state it may have a different order, > because we'd put the new commits at the end. But we run this test in > both fully-bitmapped and partial-bitmap conditions. > > We could add something like --topo-order to the expected output, but I > think even if it worked, then the bitmap-confirmation in > test_bitmap_traversal wouldn't really be checking anything! I.e., if the > "actual" traversal didn't use bitmaps, we'd still say "oh, these two > outputs are different, so one must have used bitmaps." So saying > "--no-confirm-bitmap" at least documents that we don't expect any > difference. That's a pretty good point. Thanks!
