Re: git bisect outputs list of commits in the wrong order

[Junio C Hamano <gitster@pobox.com>]

Volker Weißmann <volker.weissmann@gmx.de> writes:

> If you use `git bisect` and `git bisect skip`, you might get an output
> like this:
>
> There are only 'skip'ped commits left to test.
> The first bad commit could be any of:
> 01f793267a9af328f0f1af2cdb88301a08f007b2
> a87784e29411e8b08059fdc79629e64de3002c99
> af0df663440796a0580644493c15290405e60ecd
> 4f34b8cd48e2a814263efb319fe5dbab91215aed
> f3d91e38a45f0a2ec5affb884d536c9c4e5bb290
> 13526e1b0e1b11a2e30e44ccf35fbf92ffb61372
> abee97622db5301d593265ff6e2009777b09221e
> b63700f09a422f01d954967b84c5e662881352eb
> We cannot bisect more!
>
> While the output is correct, I don't like the fact that the commits are
> not in chronological order. Is there a reason for this? Chronological
> order makes sense and would make it easier to find the first known bad
> and the last known good commit.

Thanks for a report.

I looked at an "scripted" version in the ancient past and it seems
to have computed by iterating over

	git rev-list bisect/bad --not $good_revs

which would have given these intermediate ones roughly in the
reverse chronological order.  It could be that the behaviour
regressed when the scripted version was rewritten in C, but I dunno.

Christian (as an "area" expert for bisect), do you have any
comments?

Thanks.