From: Olliver Schinagl Date: Sat, 23 Mar 2024 20:51:28 GMT Subject: Re: Allow git bisect to auto-skip Message-ID: <4cf100aa-4239-4377-b20a-7c90443fb405@schinagl.nl> In-Reply-To: On 23-03-2024 19:43, Junio C Hamano wrote: > Stefan Haller 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. This changes my view of the issue a little bit. Building vs testing, though in reality its the same of course. I can totally see that a user would need a special bisect script to handle these cases 'this commit breaks test 54, 43 and 12; but the rest work'. This is too specific to handle generically. Probably in using a similar trick, store in the notes what works and does not work. I think it still stands that having a 'generic' way of telling bisect to skip the entire commit is still reasonable. Kind of like how you can do `git push -o ci.skip=true` with GitLab. Olliver > > Thanks.