When bisecting, I may land on some commit that is unrelated to the problem at hand but because of other completely unrelated issues (e.g., compilation failure) it cannot be marked as either 'good' or 'bad' as I can't know whether the problem I'm looking for will be before or after this commit. And this problem may last for several commits because it was not discovered immediately.

OK, those commits are certainly bad in absolute terms, but they are neither good nor bad relative to the problem at hand. So, if marked 'bad' the bisect will continue with a 50% chance in the wrong direction.

So, how do I deal with that?

Do I keep doing fossil up next or fossil up prev until I land on a good compilation and resume bisecting from there?

But in that case, I may again land on those same useless (but unrelated) commits.

Is there some way to mark those irrelevant commits as 'ignored' during bisecting so that they won't be visited again but without marking them as either 'good' or 'bad' which may produce the wrong result?

I just want them ignored during bisect as if they were never part of history.

For now, just fossil up next or fossil up prev until you land on a good compilation.

There is not currently a mechanism for marking commits as no-appropriate-for-bisect. Probably that is something that needs to be added. Do you have any suggestions on how to do so? Should we just tag those commits using a magic "do-not-bisect" tag and then teach the bisect command to ignore check-ins that have that tag? What do other systems do?

This does not come up for me so much, since I tend to only bisect on trunk, and I tend to only keep clean check-ins on trunk. But I can see how it might be an issue for different workflows.

Should the "do-not-bisect" marker (be it a tag or something else) be part of the global state that is synced to other repos, or should it be a notation that is private to each individual clone of the repository?

How to work?

I would expect something like fossil bisect skip to mark it as irrelevant never to be visited again for this bisect session only (i.e., until bisect reset), and fossil bisect purge to mark it as irrelevant for all future bisect sessions. This last one should be un-doable in case of mistakes.

I suppose the operation will be similar to this, which is I would usually do by hand.

Depending from which side one arrives (older end or newer end) when landing on an 'ignored' commit, automatically do fossil up next if coming from older side or fossil up prev if coming from newer side, until an unmarked commit is found.

I don't know what other systems do, if anything.

The only other one I use is git, which I'm forced to use when I can't get out of it, but I don't know but the basics. I can't be sure if it even has support for this.

I would think 'local' would be more appropriate as each developer may work on other parts of those commits that do not hit the compilation problem (for example). By 'local' I mean saved in the actual fossil repo, not the checkout FOSSIL one. Something that sticks to the repo but doesn't contaminate others'.

fossil bisect skip

Doesn't that basically fork the bisection? Instead of finishing in O(log₂(N)) it now finishes in O(2×log₂(M)) where M≅N/2, because it has to bisect separately on each side of the "skip" break to be sure it's ruled out all cases.

That in turn then means you get two results from a bisect, not one, e.g. {OK, BAD[abcd1234]}, meaning the left-side bisect completed successfully, but the right-side one found a bad commit localized to ID [abcd1234].

Now add multiple skips, and you'll end up with an N-tuple as a result. Blech.

Far better to just institute policies that prevent such bad commits from landing on long-lived development branches in the first place.

Apparently Git has a "bisect skip" command. The skip is only remembered for the current bisect. That should be relatively easy to implement (as nothing needs to be synced or shared). Look for it in the near future. But I have other priorities right this minute...

I tend to only bisect on trunk

I'm pretty sure I've seen bisect leave the branch it was started on and go down a contributing branch.

I don't have a repro case, because I bisect rarely, and it doesn't always happen, but if you think through the algorithm and realize I could be right, then I'd like a feature that would restrict bisect to a single branch. That would let you keep temporary insantities and local confusions partitioned away on individual developer branches, which then reduces the need for the OP's requested feature because now presumably the shared development branch always builds.

Doesn't that basically fork the bisection?

I don't think so. The way bisect works is that it constructs a path of check-ins from earliest known bad back to the latest known good (or from the earliest known good back to the latest known bad, depending on which way you are going). Then it finds the check-in in the middle. The hypothetical "fossil bisect skip" command just marks certain check-ins to exclude from this list. Probably the syntax would be of the form:

    fossil bisect skip ?CHECKIN-ID? ?CHECKIN-ID?

With no arguments, it adds the current checkout to the exclude list. With one argument, it adds the identified checkin to the list. With two arguments, it adds all checkins in the range to the list. After expanding the exclude list, the current bisect step is recomputed, possibly moving current checkout.

Unless I'm missing something, this shouldn't take too much work to implement and the changes are reasonable localized, so there is little risk of breaking something else.

Not really. Removing the bad elements from a list gives you new list to work on. You're now bisecting on this list without regard to the removed elements.

It uses path_shortest() to find the list of checkins. It tries to ignore branches by default, but if the origin and destination are on different branches, that clearly won't work. It uses branches when it has to.

If you run

    fossil bisect option direct-only off

Then the path-finding is much more willing to explore branches. I have personally never disabled the direct-only feature. Perhaps that is really a misfeature that ought to be removed?

I'm certain I've never changed that option.

My vague recollection is that the last time this caused a problem for me was because the bisect range included a merge-in point, and Fossil traced a commit back up into the contributing branch, which failed because it wasn't yet tested on all platforms the trunk needed to build on.

This is not urgent. It might happen to me once a year, kind of thing.

Your mention of "shortest path" clued me into the construction of an easy repro case, drh:

fossil init, open, etc.
echo foo > x
fossil add x
fossil ci -m 'added x' --branch foo
fossil up trunk
for n in $(seq 6) ; do fossil ci --allow-empty -m "extra commit $n" ; done
fossil merge --integrate foo
fossil ci -m 'merged foo branch'
fossil bisect bad abcd1234
fossil bisect good def789ab

The "bad" commit in the penultimate command is the initial empty commit, and the "good" commit is the merge-in point for branch foo. Because of the 6 empty commits created on trunk spanning the single-commit foo branch's lifetime, going through branch foo is the shortest path between those two points, in terms of number of commits.

You can see how this is a fairly common thing to happen: trunk is busy, and the development branch is being worked on rarely. If the bisect range spans the development branch's creation and integration points, then it's likely to be considered a better path for the bisect than staying on trunk, even though for the purposes of the bisect we don't actually care about what's gone on inside that branch, only what results at the merge-in point.

So I still want the stay-on-branch feature. :)

which then reduces the need for the OP's requested feature because now presumably the shared development branch always builds.

Two cases come to mind why this isn't so:

1. Build multiple binaries from mostly common code.
2. Build same binary under multiple different configurations.

Imagine this:

One developer works on a common library making some changes that build app A (or configuration A) successfully because the app is also updated accordingly.

Another (or the same developer) realizes some (long?) time after the commit that app B (or configuration B) broke. And there could be many binaries or configurations that doing a time consuming full build for every little change would be impractical.

So, when bisecting for a problem in app/configuration B you want to skip those coming from app/configuration A that don't allow B to even compile as certainly the problem with respect to B is in none of them.

I would think 'local' would be more appropriate as each developer may work on other parts of those commits that do not hit the compilation problem ...

Related: if someone ends up bisecting, for completely different reasons, via the same checkins, they might not want to ignore them. Presumably the do-not-bisect state would need to map to both the checkin and the bisect session.

Build multiple binaries from mostly common code.

If you're doing work on a short-lived feature branch my-new-feature, you have the chance to test on all of the platforms you need to support by checking that branch out on each one before integrating the branch back into the long-lived development branch. (The latter could be trunk, version-3, etc.)

In my projects, the rule is that you commit to long-lived development branches only when you're certain that testing on a single platform won't break other platforms you need to support.

This is an ideal not always achieved, but violations are rare.

If it happens that you commit to trunk on a single platform and find that it breaks somewhere else, you can amend the trunk tip onto a new branch, fix the problem there, and then merge it back into the newly re-tipped trunk, isolating the error.

Therefore, the only way to run into this problem is to be working on one platform and then only come back and test the other platform many commits later, when amend can no longer work. And if that is the case, can you really be said to be "testing" on the other platform at all?

there could be many binaries or configurations that doing a time consuming full build for every little change would be impractical.

If switching configurations is painful, you probably aren't making full use of Fossil's ability to have multiple checkouts per repo. Example:

fossil ci --branch my-new-feature
...hack, hack, hack...
fossil ci -m 'prototype functionally complete'
cd ../configuration-b      # where you gave different ./configure args
fossil up my-new-feature
make all test

The last two commands should change only the files modified on branch my-new-feature relative to the long-lived development branch, so a rebuild and test should go quickly. The rest of the object files don't need to be rebuilt because they're based on sources those two branches hold in common.

That's the "fossil bisect option direct-only on" setting, which is the default, if I understand correctly.

Here is a more concrete example. Consider the graph at https://fossil-scm.org/fossil/timeline?p=8530666c&bt=e58c76a1 and:

   fossil bisect reset
   fossil bisect good e58c76a1d0d6a3bc
   fossil bisect bad 8530666c0986ee34

With "direct-only" on, the bisect stays on trunk. With "direct-only" off, the bisect follows the branch. You can see the path it takes by running "fossil bisect vlist".

What does "fossil bisect options" show as your direct-only setting? It says "on" for me, which means that bisects stay on trunk when they can. Is that seems to be the default, at least when I try it.

What does "fossil bisect options" show as your direct-only setting?

I thought it was clear from my repro case that you can cause this to happen on a newly-created repo, which means all settings are at their defaults.

However, I think we have a case of local brain damage here. I saw the "CURRENT" go to a commit that spans the branch in that false repro case, but it wasn't on the branch.

If I see this happen in the wild again, I'll try to see what's going on in Fossil's brain at the time. Until then, consider this branch of the thread to be noise. fossil amend --close --hide. :)

Very right!

Like I said in another example, (between app A and B) certain checkins when looking for problems in A should not be skipped over but those same ones could be skipped when checking for problems in B.

However, there are few less common cases where a commit introduced a problem so serious that you wish that commit never happened. And because of other commits which followed you can't just purge it from the middle of history. But, you possibly want to mark that checkin for permanent exclusion from the bisect list. Actually, not only the bisect list. I would rather see it permanently banned from the 'timeline' also, so that fossil up next/prev would always skip over it. The only way to go there would be to explicitly give its commit hash ID.

you can't just purge it from the middle of history.

You should almost never use purge anyway.

1. I believe sync will reintroduce purged artifacts, bidirectionally. The only way to reliably purge everywhere is to stop syncing and manually go around and run the same purge command on every repo before re-enabling syncing.

2. If I'm right that problem #1 exists, and it affects you, then you should be using /shun instead, possibly in combination with the auto-shun setting.

3. fossil merge --backout is far less destructive than either purge or shun. Bisecting and other historical explorations aside, it has the same effect without the same bad side-effects.

I would rather see it permanently banned from the 'timeline' also

At that point, you're off into an incompatible philosophy with respect to Fossil's design.

Yes, rebase is relevant here, because in order to completely elide a commit from the middle of history without leaving a gap, you're going to end up re-hashing all subsequent commits, which has the well-known effects on the integrity of the blockchain from that point forward. Thus Git's "never rebase in public" rule.

At that point, you're off into an incompatible philosophy with respect to Fossil's design.

I didn't say I want that checkin to disappear from the middle of history, which I believe what git rebase would help do. (So, I remain compatible with Fossil's design!)

Of course, if it is at the tip of the branch, and I'm the sole developer I do have the luxury to purge it, otherwise a merge --backout is the only way to go. Exactly then is when you would want to stop visiting it by 'accident'.

I don't want to visit it casually because it's almost always pointless. I do want to see it in the timeline (if I didn't/couldn't purge it) but not go to it by either next/prev or bisect. What for? It's a waste of time.

But certainly I want to be able to visit all commits when I call them by their hash: fossil up hash_id.

Of course, if it is at the tip of the branch, and I'm the sole developer I do have the luxury to purge it, otherwise a merge --backout is the only way to go.

Another option when it's the tip of the branch is to move the bad checkin on a branch (example: mistake). Optionally you also can add the "hidden" tag to don't see it by default on the timeline.

I have also seen what Warren saw. Bisect between two trunk revisions ended up on revision committed to a branch.

The branch was created and merged between the two initial trunk revisions. I would have been using default settings, so direct-only=on.

This was a problem, because the code I was trying to fix/identify was rewritten (and later abandoned) on the branch. So running the branch revision was not useful. Having a skip capability would have been very useful as well.

I ended up doing multiple bisects so that the branch revision wasn't chosen.

I have also seen what Warren saw. Bisect between two trunk revisions ended up on revision committed to a branch.

If you can devise a test case, that would be helpful.

I think fixing Warren's test case would do it. (Ugg, just realized Warren's test case isn't valid according to his later comment.)

IIRC the main line had a bunch of commits in it and the branch had fewer commits.

I'll check my repo to see if I can find the bisect I was doing. That will give you a live example. But I am not sure where in the previous three years the bisect was being done. So I won't tell you to hold your breath 8-/.

-- rouilj

I may land on some commit that is unrelated to the problem at hand but because of other completely unrelated issues ... it cannot be marked as either 'good' or 'bad'

Now on trunk is a third option:

     fossil bisect skip

Please try it out and report back on this thread if you find any problems.

It seems like the skip option was not added in the bisect help.

I mean here:

fossil bisect
Usage: fossil bisect bad|good|log|next|options|reset|status|undo

Here you go:

$ f diff --from prev
Index: src/bisect.c
...
-    usage("bad|good|log|next|options|reset|status|undo");
+    usage("bad|good|log|next|options|reset|skip|status|undo");
...

$ f ci -m "Added 'skip' to bisect's one-line help summary."
...
New_Version: 4689ec45f95f7204cce9a7a7967b52de4af4f137ec1df6424b581870c2409454
...

You should modify line 609 as well (e.g. for fossil bisect -h or fossil bisect fakecommand).