On 23-03-2024 21:51, Olliver Schinagl wrote:
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.
P.S. One (imo big) issue to me is, that notes aren't automatically
fetched or pushed according to what I found so far online (haven't
personally tested it yet).
If that is the case, this makes the feature to be used in combination
with bisect much more difficult for the un-informed. having a
`refs/notes/<bisect-or-like-related-name>` notes tree is great, but only
if it gets automatically pulled.
I think this also might be the reason it is a very undervalued thing maybe?
Olliver
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.
