[BUG] Git bisect extends bisecting range on repeated good/bad data

[BUG] Git bisect extends bisecting range on repeated good/bad data

[Maxim Kuvyrkov]

Hi,

Git bisect may /extend/ bisection range on repeated good/bad data.  Is this expected?

E.g., try in gcc-mirror repository (tested with git:master and Ubuntu 18.04 git 2.17.1):

git clone https://github.com/gcc-mirror/gcc.git
cd gcc
git bisect start
git bisect bad 81018e27c829e3f09bfe7ce331f14d9fdc995073
git bisect good ab9c3f0f3cabc7069ff0edc040206f1b82eef4ef
git bisect bad 6dc6f6c30298f89e725b0e9328775ed43e08e007

... says there are 0 revisions left to test after this (roughly 1 step).

But if we re-run:

git bisect bad 81018e27c829e3f09bfe7ce331f14d9fdc995073

... suddenly -- 15 revisions left to test after this (roughly 4 steps).

This is reduced from a real-world bisection between GCC's gcc-8-branch and gcc-9-branch:
===
git bisect start 
git bisect good 2127e4096ab452a8f0d3e878cb3a4081b3402f1f
git bisect bad 81018e27c829e3f09bfe7ce331f14d9fdc995073
git bisect skip 941fafa56b52ee2328a8695c22e66301b8d30d5e
git bisect good 4c0c3d1029e79b6709b43fed8c5a5944f245516d
git bisect good d9c42406016fee5c0593b7e584135cf40342308d
git bisect good 6f9d77939fc5b55f4c50122b8dc06e6305480bd0
git bisect good 01b38cb1143f17e7ad5b4e863dd60ff42b64c9fd
git bisect good 28e329000fe8a36f059a9b30096a5d226231b4a5
git bisect good 44b2b4ce5d18e915e23f474a64a1a96490d48e82
git bisect good 22bf0cb640189880b683180d50b1e5b4b93e1fd9
git bisect good ab9c3f0f3cabc7069ff0edc040206f1b82eef4ef
git bisect bad 0f18417db316878818d997ae4e9d4e2f8520b2aa
git bisect bad 76c09fb0bcb5785830a24f1f0bec6a6d4f22949d
git bisect bad 6dc6f6c30298f89e725b0e9328775ed43e08e007

git bisect bad 81018e27c829e3f09bfe7ce331f14d9fdc995073
===

Regards,

--
Maxim Kuvyrkov
https://www.linaro.org

Re: [BUG] Git bisect extends bisecting range on repeated good/bad data

[Junio C Hamano]

Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> writes:

> Git bisect may /extend/ bisection range on repeated good/bad data.  Is this expected?

It is not "repeated" that is an issue, but yes this is expected.

The bisection works by finding a mid point to cut the graph into two
pieces of roughly the same size, and the graph is defined by the
set of good commits on the bottom (i.e. "we were told that all these
good commits were good, so there is no point going back the history
beyond any of them") and the single "bad" commit you gave the last.

If you give 'bad' that is in the newer part of the history than the
one that is already known to be bad, then you rewind that single
"bad" commit, to force/allow the machinery to recompute the midpoint
[*1*], and because the area to search would be wider when you do so,
it is very much expected that you'd be offered to test more commits.



[Footnote]

*1* I said force/allow is because allowing the machinery to go back
    and recompute is a way to recover when you gave a "bad" earlier
    by mistake.

Re: [BUG] Git bisect extends bisecting range on repeated good/bad data

[Maxim Kuvyrkov]

> On Dec 13, 2019, at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Maxim Kuvyrkov <maxim.kuvyrkov@linaro.org> writes:
> 
>> Git bisect may /extend/ bisection range on repeated good/bad data.  Is this expected?
> 
> It is not "repeated" that is an issue, but yes this is expected.
> 
> The bisection works by finding a mid point to cut the graph into two
> pieces of roughly the same size, and the graph is defined by the
> set of good commits on the bottom (i.e. "we were told that all these
> good commits were good, so there is no point going back the history
> beyond any of them") and the single "bad" commit you gave the last.
> 
> If you give 'bad' that is in the newer part of the history than the
> one that is already known to be bad, then you rewind that single
> "bad" commit, to force/allow the machinery to recompute the midpoint
> [*1*], and because the area to search would be wider when you do so,
> it is very much expected that you'd be offered to test more commits.
> 
> 
> 
> [Footnote]
> 
> *1* I said force/allow is because allowing the machinery to go back
>    and recompute is a way to recover when you gave a "bad" earlier
>    by mistake.
> 

Hi Junio,

Thank you for the answer.

--
Maxim Kuvyrkov
https://www.linaro.org