Re: [git-for-windows] Re: Continuous Testing of Git on Windows

From: Philip Oakley <philipoakley@iee.org>
Date: Feb 15, 2017, 21:06 UTC
Message-ID: <7EA15219331242ABB08B9A9AA9F08CBE@PhilipOakley>
In-Reply-To: <xmqqshng5osz.fsf@gitster.mtv.corp.google.com>

From: "Junio C Hamano" <gitster@pobox.com>

Show 9 quoted lines

> "Philip Oakley" <philipoakley@iee.org> writes:
>
>> There are also a few ideas at the SO answers:
>> http://stackoverflow.com/a/5652323/717355
>
> I vaguely recall that I saw somebody said the same "mark tips of
> topics as good" on the list and answered with why it does not quite
> work, though.
>

I think you may mean https://public-inbox.org/git/7v8vyam5la.fsf@alter.siamese.dyndns.org/

I think we are thinking of opposite abstractions.

For regular bisect, the assumption (to a first order) is that there is a single point of infection of a single persistent bug with a well defined test, and that the goal is to find the point of first infection, as all other incidents of the bug are in successor commits, which are all infected. The fail-fix-break again sequence you mentioned in that thread is to my mind a red herring as it contradicts the normal bisection assumptions (but see below).

In the next..pu case the abstraction is in the other direction, we have potentially multiple points of infection (from feature branches), and a broad test (the whole test suite). In this case I believe we would like to investigate initially the --first-parent line with a classic bisect for the first point of failure (obviously including feature branch merges). This would identify which feature merge, or regular commit, created the first breakage.

Once the first point of failure has been identified, for the next..pu case, each of the post-fail second parents of merge commits _could_ then also be checked (which is a linear search, not a bisection), to identify any additional feature branches that need attention. This second stage search would probably be an option, but if the merging sequence onto pu is generally from good to bad, then the search is likely to be short. At least for a CI system this 2nd stage could provide useful feedback to the authors of their mistakes...

I haven't looked back at the actual patches in that thread, so they may not have followed my expectation of the --multi-bug (TM) search algorithm. --

Philip