Re: [PATCH] bisect: error out when given any good rev that is not an ancestor of the bad rev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le mardi 1 juillet 2008, Junio C Hamano a écrit :
> Christian Couder <chriscool@xxxxxxxxxxxxx> writes:
> > Before this patch "git bisect" doesn't really work when it is given
> > some good revs that are siblings of the bad rev.
> >
> > For example if there is the following history:
> >
> > A-B-C-D
> >    \E-F
> >
> > and we launch "git bisect start D F" then only C and D will be
> > considered as possible first bad commit. This is wrong because A, B and
> > E may be bad too if the bug exists everywhere except in F that fixes
> > it.
>
> Please don't.
>
> bisect is about finding a single regression by partitioning the graph
> into older good section and newer bad section with a *single* "first bad
> commit".
>
> For your "this could also be possible" scenario is already outside the
> realm.  You are assuming A, B and F is good, and D is bad.

I am assuming the first bad commit in the graph is A and it is fixed by F.

> But if E is 
> bad, then that breakage cannot possibly affect the transition between B
> and D from good to bad (E cannot break D), so C must *also* be bad.

Yes, I assume C is also bad.

> ... which means you are dealing with *two* breakages.  That's outside
> what bisect deals with.

Sorry, I don't understand why I am assuming 2 breakages.

> And this does not need to have forked development.  If the graph were
> like this:
>
>   A-B-C-D-E-F
>
> and if F is bad and B is good, with your logic, after checking that D is
> already bad, we cannot discount E --- after somehow fixing D, we _might_
> also be introducing another breakage with E.  You cannot even check for
> that anyway, but the logic is the same.

I don't think the logic is the same because in your case git bisect will 
report one first bad commit anyway even if this bad commit has been fixed 
latter.

In my case above, git bisect currently considers C and D as the only 
possible bad commits because when it is told that F is good, it assumes 
that all the ancestors or F are good too. And this means that B is 
considered good so C will be found as the first bad commit. I think this 
can be really misleading because there is no good->bad transition between B 
and C.

Regards,
Christian.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux