Show 30 quoted lines
> 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.
Derrick Stolee <stolee@gmail.com>