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. -Peff
