Re: git bisect for reachable commits only

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

 



Christian Couder <christian.couder@xxxxxxxxx> writes:

>> I think the "previous issue" was that we can ask the user to ask to
>> check one of 'x' or 'y' when given Good and Bad points in a graph like
>> this:
>>
>>         x---y---y---o---B
>>          \         /
>>           x---G---o
>>
>> while a more natural expectation by a user would be that we only
>> need to check one of these two 'o'.
>
> Yeah, I reproduced the steps described in the Google Groups discussion:
>
> https://groups.google.com/forum/#!topic/git-users/v3__t42qbKE
>
> and I think that is indeed the "previous issue".
>
>> Thinking about it again, I actually think it makes sense to ask the
>> user to check 'y'; there is no good reason to believe that 'y' can
>> never have introduced the badness we are hunting for, and limiting
>> the search to --ancestry-path (which is to ask only for 'o') would
>> stop at the merge 'o' if one of the 'y' were bad, which would
>> prevents us from knowing the exact breakage.
>
> I agree.

Having agreed on that, there are cases where you do want to stop at
the merge 'o' on the upper history, when lower-history leading to B
is the mainline and you are interested in finding the merge with
which side branch introduced a breakage, and not particularly
interested in finding the exact commit on the side branch.  Upon
finding the merge 'o' that is the parent of 'B' is bad, you find out
the owner of the side branch merged there who wrote the two 'y's,
and have him work on figuring out where in his branch he broke it.

For that, the --ancestry-path is a wrong way to traverse; what we
want in that context is the --first-parent traversal.

>> There however is no excuse if we asked to check 'x', though.  They
>> are ancestors of a Good commit, and "git bisect" should be able to
>> assume they are Good.
>
> I think it does. When I reproduced the steps in the "previous issue",
> it did assume they are good.

I actually had an impression that the original report claimed that
the user was asked to check immediate parent of G, and that would be
a bug.
--
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]