Re: Allow git bisect to auto-skip

From: Christian Couder <christian.couder@gmail.com>
Date: Mar 24, 2024, 14:29 UTC
Message-ID: <CAP8UFD2DhkmVias+RfMESJz9Z-rKKHWHB+MFHcDb9QLO16TOhg@mail.gmail.com>
In-Reply-To: <e896da79-c87b-4475-9890-10051d8ddf76@haller-berlin.de>

On Sun, Mar 24, 2024 at 11:16 AM Stefan Haller <lists@haller-berlin.de> wrote:

Show 27 quoted lines

>
> On 23.03.24 19:43, Junio C Hamano wrote:
> > Stefan Haller <lists@haller-berlin.de> writes:
> >
> >> On 22.03.24 23:31, Junio C Hamano wrote:
> >>> It often is discovered that a commit
> >>> breaks bisection after the fact and it is not feasible to rebase
> >>> all the history after the commit.
> >>
> >> This reminds me of a similar problem with git blame, for which we have
> >> the blame.ignoreRevsFile config to work around it. Couldn't there be a
> >> similar mechanism for bisect, e.g. bisect.skipRevsFile?
> >
> > A Very good point.  If a breakage of a commit is "this does not even
> > build" kind of breakage, such a mechanism would be an excellent fit.
> >
> > But if a breakage is "only this particular test fails and we know
> > the reason why it fails has nothing to do with the bug we are
> > chasing", then compiling such a fixed list of commits, or pointing
> > at such a list with a configuration variable, would not work very
> > well, I am afraid.
>
> That's true, but the same can be said about blame.ignoreRevsFile. There
> may be commits that contain both uninteresting whitespace changes and
> real changes (not in a well-maintained project of course :-), so it
> wouldn't be a good idea to add those to blame.ignoreRevsFile. But that's
> not a reason not to offer the feature at all.

I am not against the feature, but I think it would be especially useful if the file(s) containing the revs that should be skipped is(are) tracked in Git. In this case though, any such file wouldn't be used automatically after cloning the repo as the bisect.skipRevsFile option would still need to be configured.

Also, how much better would this be compared to tracking "git bisect run" scripts in the repo, even if they have to be copied somewhere else before they are launched? I wonder about this because writing the conditions that decide whether the current commit is good or bad might not be so easy either. So if the goal is to simplify things for users, then simplifying all the way by providing example scripts with comments about how they could be customized might be even better.