On 23-03-2024 19:43, Junio C Hamano wrote:
Stefan Haller <lists@xxxxxxxxxxxxxxxx> 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.
