Fossil Forum

How to skip commits during bisect?

How to skip commits during bisect?

(1) By anonymous on 2020-07-09 13:58:44 [link] [source]

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.

(2) By Richard Hipp (drh) on 2020-07-09 14:13:37 in reply to 1 [link] [source]

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.

(3) By Richard Hipp (drh) on 2020-07-09 14:15:25 in reply to 2 [link] [source]

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?

(5) By anonymous on 2020-07-09 14:37:58 in reply to 3 [link] [source]

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'.

(15) By Stephan Beal (stephan) on 2020-07-09 15:51:54 in reply to 5 [link] [source]

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.

(19) By anonymous on 2020-07-09 16:16:06 in reply to 15 [link] [source]

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.

(20) By Warren Young (wyoung) on 2020-07-09 16:32:24 in reply to 19 [link] [source]

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.

(21) By anonymous on 2020-07-09 16:58:40 in reply to 20 [link] [source]

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.

(22) By Martin Gagnon (mgagnon) on 2020-07-09 17:46:26 in reply to 21 [link] [source]

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.

(25) By Andy Bradford (andybradford) on 2020-07-09 19:55:42 in reply to 3 [link] [source]

Shouldn't any of this  state be part of the bisect  session only and not
persisted  in the  repository  proper? Seems  like  just adding  "bisect
ignore" should cover  it and it goes away when  I clear/reset the bisect

I  may not  want to  ignore the  same thing  a second  time around,  and
committing things to be ignored just seems more than necessary.

Just my thoughts.


(4) By anonymous on 2020-07-09 14:33:15 in reply to 2 [link] [source]

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.

(6) By Warren Young (wyoung) on 2020-07-09 14:55:54 in reply to 4 [link] [source]

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.

(9) By Richard Hipp (drh) on 2020-07-09 15:03:12 in reply to 6 [link] [source]

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.

(10) By anonymous on 2020-07-09 15:08:53 in reply to 6 [link] [source]

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.

(7) By Richard Hipp (drh) on 2020-07-09 14:56:13 in reply to 4 [link] [source]

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...

(8) By Warren Young (wyoung) on 2020-07-09 14:59:44 in reply to 2 [link] [source]

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.

(11) By Richard Hipp (drh) on 2020-07-09 15:09:24 in reply to 8 [link] [source]

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?

(12) By Warren Young (wyoung) on 2020-07-09 15:17:05 in reply to 11 [link] [source]

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.

(13) By Warren Young (wyoung) on 2020-07-09 15:34:54 in reply to 12 [link] [source]

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. :)

(17) By Richard Hipp (drh) on 2020-07-09 16:02:39 in reply to 13 [link] [source]

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 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.

(18) By Warren Young (wyoung) on 2020-07-09 16:10:48 in reply to 17 [link] [source]

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. :)

(23.1) By John Rouillard (rouilj) on 2020-07-09 17:59:38 edited from 23.0 in reply to 18 [link] [source]

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.

(24) By Richard Hipp (drh) on 2020-07-09 18:09:32 in reply to 23.1 [link] [source]

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.

(26.1) By John Rouillard (rouilj) on 2020-07-09 20:34:34 edited from 26.0 in reply to 24 [link] [source]

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

(14) By anonymous on 2020-07-09 15:41:14 in reply to 8 [link] [source]

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.

(16) By Warren Young (wyoung) on 2020-07-09 15:53:23 in reply to 14 [link] [source]

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.

(27) By Richard Hipp (drh) on 2020-07-09 20:46:48 in reply to 1 [link] [source]

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.

(28) By anonymous on 2020-07-09 23:56:07 in reply to 27 [source]

First of all, thanks for the immediate solution.

My observations: It appears to work correctly from a technical point of view.

I tried it on a problem than was unluckily present for two whole months with a few hundred commits in between, and it took forever... so that after 130 skips I gave up.

When I first hit an indifferent commit, I skipped it, and then it started going around it, one up one down, a good scheme in theory as it maintains closeness to the last good midpoint. However, I was unlucky to start (after a few good/bad) somewhere near the middle of the problem. So, it was a very long way to spiral out of it, one sequential commit at time.

So, although it works from a technical point of view, in my case it turned out to be impractical. I would have skipped more commits if doing it by hand and come to the solution faster.

So, maybe some speed improvement is possible for pathological cases as the above.

My thought is (and it could be flawed) that on average, problems to skip are usually present in one or more consecutive commits (in my example a few hundred of them), so maybe a speed improvement would be possible by going up/down more steps at a time, say 10% of the overall span of the bisect. It won't change the number of tries for the worst case scenario and it may be a little bit uneven bisect, but it may give more chance to find the problem outside the skipped commits faster.

So, once a hit a skip, I would assume a number of surrounding commits to be also affected and try to get a bit further away than just one commit.

Does it make sense?

Don't get me wrong, I'm not complaining in any way, it does work! Many thanks again.

But maybe it can be optimized somewhat to finish the bisect a bit faster.

Here's my attempt that I gave up:

 "fossil undo" is available to undo changes to the working checkout.
span: 284  steps-remaining: 9
  1 BAD     2020-07-08 18:35:53 c56f97e21214556b
134 SKIP    2020-05-07 14:32:07 a3c790fccd9ad6c5
133 SKIP    2020-05-07 13:19:51 7b134da7129a9742
130 SKIP    2020-05-06 18:27:07 d865b19d1933186b
128 SKIP    2020-05-06 18:26:20 7695e05d88c1c882
126 SKIP    2020-05-06 18:21:46 f7281bfdaa4a7874
124 SKIP    2020-05-06 18:05:46 d9a5ca2c079af7c9
122 SKIP    2020-05-06 16:48:11 fd501eac0169fc6b
120 SKIP    2020-05-06 16:44:19 5ab5027aa1cc491d
118 SKIP    2020-04-29 14:01:51 8c9e246f30a087c6
116 SKIP    2020-04-29 13:35:28 6d684f21c9a3bf7e
114 SKIP    2020-04-29 01:02:40 c7726eb3303b3f07
112 SKIP    2020-04-29 01:01:22 cc75717f6c6f1429
110 SKIP    2020-04-29 00:49:44 d134d0cafd42fffb
108 SKIP    2020-04-29 00:48:59 3b6f42f371b42472
106 SKIP    2020-04-29 00:32:41 bac59466585b26a4
104 SKIP    2020-04-29 00:28:42 a174c80a57834add
102 SKIP    2020-04-28 19:10:30 b906914a0b44edc8
100 SKIP    2020-04-28 18:17:47 d2ef35b46f518ba2
 98 SKIP    2020-04-28 17:35:32 d88fc54b720c960b
 96 SKIP    2020-04-28 17:15:19 c6ba05b617c195b7
 94 SKIP    2020-04-28 15:48:11 05811fb5799b608d
 92 SKIP    2020-04-21 17:22:51 0fdd7d345a5473e8
 90 SKIP    2020-04-21 14:09:12 c332ca41e5007acf
 88 SKIP    2020-04-21 13:52:14 039fe3400eaf5de7
 86 SKIP    2020-04-17 16:39:57 3dd3a9ee5d2fefbe
 84 SKIP    2020-04-17 13:34:47 3e45c26147f30ea3
 82 SKIP    2020-04-16 15:33:56 32d930a297b21558
 80 SKIP    2020-04-16 14:41:32 d9f1344660c2cafa
 78 SKIP    2020-04-13 10:19:47 8702d04ffa32667a
 76 SKIP    2020-04-08 10:17:24 06aeb8ebe11993fa
 74 SKIP    2020-04-08 10:10:48 7956cedf39941e6c
 72 SKIP    2020-04-08 09:52:49 ab9bac49bdc2ffe8
 70 SKIP    2020-04-08 07:34:28 839217b67c645059
 68 SKIP    2020-04-03 17:02:14 422b1bccd44cbda0
 66 SKIP    2020-04-03 16:58:49 44e1cd6a0d03b95b
 64 SKIP    2020-04-03 16:38:41 066810280c4d3c0c
 62 SKIP    2020-04-03 16:32:00 04983444d99a5b89
 60 SKIP    2020-04-03 16:23:59 a7360e805829929b
 58 SKIP    2020-04-03 16:19:00 b3446cb7998a7073
 56 SKIP    2020-04-03 16:12:43 9ce7709ba5b9376e
 54 SKIP    2020-04-03 16:08:15 f6453eb617843db2
 52 SKIP    2020-04-03 15:45:42 c56f68e595abc49d
 50 SKIP    2020-04-03 15:35:24 36438f3e871f899e
 48 SKIP    2020-04-03 15:34:15 e5448c65ba4cdbf0
 46 SKIP    2020-04-03 14:57:21 333b61f00fe6a392
 44 SKIP    2020-04-03 14:41:43 88e67f85bba0339d
 42 SKIP    2020-04-03 14:26:11 693ba377143cbf5c
 40 SKIP    2020-04-03 13:58:48 def68e601f682bdf
 38 SKIP    2020-04-03 11:34:14 d821cefbc2a16e63
 36 SKIP    2020-04-01 17:12:10 580b84c97df417d0
 34 SKIP    2020-04-01 10:06:59 9ee4c754743b49fa
 32 SKIP    2020-04-01 10:00:01 e8100b787f6cd896
 30 SKIP    2020-04-01 09:44:24 1ab99a22acecef00
 28 SKIP    2020-04-01 09:32:29 f71f55d06f1198d6
 26 SKIP    2020-04-01 09:17:22 f484736d7b923c80
 24 SKIP    2020-04-01 08:42:04 85e3b369fcbfdd19
 22 SKIP    2020-04-01 08:28:32 06d9631f6ad61df8
 20 SKIP    2020-03-31 23:45:07 4e7ed075e51794a7
 18 SKIP    2020-03-31 23:43:38 fcdf91642b2cd952
 16 SKIP    2020-03-31 23:32:41 c7cddcbe835976b2
 14 SKIP    2020-03-31 23:25:03 7438a642d3399541
 12 SKIP    2020-03-31 23:22:37 a21ef9b7de7f78b1
 10 SKIP    2020-03-31 23:09:53 98f8a6c19ecc641b
  8 SKIP    2020-03-31 23:06:53 826e807998d80f18
  7 SKIP    2020-03-29 23:53:43 33fc683d9fd32d56
  9 SKIP    2020-03-29 23:41:02 2461e75f9476f06d
 11 SKIP    2020-03-29 15:36:21 e4f595590ca13672
 13 SKIP    2020-03-29 15:19:22 8426b52d74e93392
 15 SKIP    2020-03-29 15:16:06 97f605da82b0a07c
 17 SKIP    2020-03-29 14:55:07 f05ea5175285e4c2
 19 SKIP    2020-03-29 14:52:58 0f7dd0f2e8ea03a7
 21 SKIP    2020-03-29 14:51:04 8758e2bc32ff470f
 23 SKIP    2020-03-29 14:33:43 9a6e7c60a2351159
 25 SKIP    2020-03-29 14:30:24 6e2d9578f7358fac
 27 SKIP    2020-03-29 14:29:48 53f77d0cde327ed1
 29 SKIP    2020-03-29 14:22:53 798f94b04f0a46c4
 31 SKIP    2020-03-29 13:32:31 e9576ecc1facecde
 33 SKIP    2020-03-29 13:21:28 e9bfb79928e2c535
 35 SKIP    2020-03-28 17:48:04 6afb31ea5bda1251
 37 SKIP    2020-03-28 17:46:27 8a4b514a5eb73fc5
 39 SKIP    2020-03-28 17:35:07 a5c8c7f87340795c
 41 SKIP    2020-03-28 17:30:10 628ee4eaaaed2c8a
 43 SKIP    2020-03-28 17:25:45 b6551a4fa32d0c62
 45 SKIP    2020-03-28 17:05:59 127eaa19c1db2053
 47 SKIP    2020-03-28 00:08:25 4edcd341b5b2ef85
 49 SKIP    2020-03-28 00:04:48 15a1925022db92d5
 51 SKIP    2020-03-28 00:03:42 3ff2c6f4dab9ed46
 53 SKIP    2020-03-27 15:14:23 1d03988784c662fc
 55 SKIP    2020-03-27 15:12:11 da95e3ecb265ecb6
 57 SKIP    2020-03-27 15:09:44 903104eaae2af0ba
 59 SKIP    2020-03-27 15:05:33 491ac712fe8e51ae
 61 SKIP    2020-03-27 14:53:08 47e1139f3221a551
 63 SKIP    2020-03-27 14:06:02 47ed5629c81a7497
 65 SKIP    2020-03-27 14:00:53 a97a55eb8a68da76
 67 SKIP    2020-03-27 13:53:27 47f8bea68680bce2
 69 SKIP    2020-03-27 12:29:06 0f6aee2338d1a646
 71 SKIP    2020-03-27 10:25:31 817e1723c18876d4
 73 SKIP    2020-03-27 00:55:10 667819eb272803e6
 75 SKIP    2020-03-25 21:04:55 bff6f59b7fa7b033
 77 SKIP    2020-03-25 21:03:32 d6eaea930b3a3f96
 79 SKIP    2020-03-25 19:01:32 f780e9b267f8fa87
 81 SKIP    2020-03-25 18:21:31 2c94da6c02160d2d
 83 SKIP    2020-03-25 14:19:16 4a11159db387de2c
 85 SKIP    2020-03-17 16:21:17 2097941ad02f8912
 87 SKIP    2020-03-16 14:52:24 bc70d315f0044b9d
 89 SKIP    2020-03-13 08:11:54 4a70657b10fd7960
 91 SKIP    2020-03-12 23:59:00 81a6a59d9767dfff
 93 SKIP    2020-03-12 23:56:11 42f192287b1ec200
 95 SKIP    2020-03-12 23:36:32 c8545f069ddc9213
 97 SKIP    2020-03-12 16:04:06 6ef1a6f52df80e66
 99 SKIP    2020-03-12 15:14:24 9c15d5f56121eaf7
101 SKIP    2020-03-12 14:39:35 1992cd4a0828c806
103 SKIP    2020-03-12 14:25:35 6388b57fbbbdc05d
105 SKIP    2020-03-12 14:20:05 fa3f32dff4cd95b5
107 SKIP    2020-03-12 14:17:42 491a4f0ebff7694c
109 SKIP    2020-03-11 17:49:47 8f10fc6af751df5c
111 SKIP    2020-03-11 16:55:52 c8103d9f52dad1c5
113 SKIP    2020-03-10 19:49:18 6f0924224d223052
115 SKIP    2020-03-10 19:37:34 3a4e75a4cf83cd14
117 SKIP    2020-03-10 19:35:14 4232b6befbd3400a
119 SKIP    2020-03-10 19:33:55 67c6bebfe624cd30
121 SKIP    2020-03-10 19:08:12 2b35cb1d4739c76a
123 SKIP    2020-03-10 18:57:43 a5e0b791edcd1ffd
125 SKIP    2020-03-07 09:13:50 74ed16783f1ebda7
127 SKIP    2020-03-04 23:45:45 f69b7f9cb1e8a004
129 SKIP    2020-03-04 23:15:00 294315ec103fc396
131 SKIP    2020-03-04 18:21:09 98180811c3936435
135 CURRENT 2020-03-04 12:42:38 4c8f4ab91991d929
132 SKIP    2020-02-12 11:46:56 26d6d1e8e11f4743
  6 GOOD    2020-01-27 08:12:10 9e4f903d0131c66d
  3 GOOD    2019-12-03 13:58:55 53d4c9126e68d153
  2 GOOD    2019-04-09 13:18:09 eec53ab5b32bbccd

(29) By anonymous on 2020-07-14 14:27:29 in reply to 27 [link] [source]

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

(30) By anonymous on 2020-07-14 14:29:48 in reply to 27 [link] [source]

I mean here:

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

(31) By Stephan Beal (stephan) on 2020-07-14 14:40:29 in reply to 30 [link] [source]

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

(32) By ddumitriu on 2020-07-16 09:52:59 in reply to 31 [link] [source]

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