On Sunday, March 24, 2024 10:29 AM, Christian Couder wrote: >On Sun, Mar 24, 2024 at 11:16 AM Stefan Haller <lists@xxxxxxxxxxxxxxxx> wrote: >> >> On 23.03.24 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. >> >> 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. In some situations, git bisect is used for compile issues, while others in debugging. In development branches, bisect is sufficient. However, if one has multiple production deploy branches, where feature merge squash happens multiple times into multiple branches, this makes finding the offending commit using bisect rather difficult as the defect may come in and out depending on the order in which feature branches are squashed (some may have the bug, while others don't). I can see the point of teaching bisect to knowingly skipping specific versions in this setting, although it is arguable that the investigation probably should not happen on the destination branches where functional stability cannot be guaranteed. But this brought up a thought. What if bisect had the notion of parallel context: Meaning running two (or more) bisects in parallel on the same repo in search of two semi-independent defects, then analysing convergence between the two analyses - something like bisect 1: A(good) B(good) C(bad) D(bad); bisect 2: A(good) B(good) C(good) D(bad); bisect 3: A(good) B(bad) C(good) D(bad), <- a production-like branch with an interpretation that C and D may have interrelated defects but started showing in B in one situation. This is not a well-baked thought, but I can see this having some relevance when sub-modules are involved and bugs exist in more than one sub-module with bisects happening in the main repo. [note: I am not certain where I am going with this idea as of yet]. --Randall
