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

"Philip Oakley" [off-list ref] 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.

From: "Junio C Hamano" <redacted>

"Philip Oakley" [off-list ref] writes:

quoted

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

From: "Junio C Hamano" <redacted>

"Philip Oakley" [off-list ref] writes:

quoted

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

From: "Junio C Hamano" <redacted>

"Philip Oakley" [off-list ref] writes:

quoted

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