How to skip commits during bisect?
(1) By anonymous on 2020-07-09 13:58:44 [link]
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]
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]
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?
(4) By anonymous on 2020-07-09 14:33:15 in reply to 2 [link]
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.
(5) By anonymous on 2020-07-09 14:37:58 in reply to 3 [link]
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'.
(6) By Warren Young (wyoung) on 2020-07-09 14:55:54 in reply to 4 [link]
> `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.
(7) By Richard Hipp (drh) on 2020-07-09 14:56:13 in reply to 4 [link]
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]
> 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.
(9) By Richard Hipp (drh) on 2020-07-09 15:03:12 in reply to 6 [link]
> 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]
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.
(11) By Richard Hipp (drh) on 2020-07-09 15:09:24 in reply to 8 [link]
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]
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]
Your mention of "shortest path" clued me into the construction of an easy repro case, drh: ```shell 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. :)
(14) By anonymous on 2020-07-09 15:41:14 in reply to 8 [link]
> 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.
(15) By Stephan Beal (stephan) on 2020-07-09 15:51:54 in reply to 5 [link]
> 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.
(16) By Warren Young (wyoung) on 2020-07-09 15:53:23 in reply to 14 [link]
> 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: ```shell 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.
(17) By Richard Hipp (drh) on 2020-07-09 16:02:39 in reply to 13 [link]
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.
(18) By Warren Young (wyoung) on 2020-07-09 16:10:48 in reply to 17 [link]
> 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`. :)
(19) By anonymous on 2020-07-09 16:16:06 in reply to 15 [link]
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]
> 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][1]. 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][2] 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. [1]: https://fossil-scm.org/home/help?cmd=auto-shun [2]: https://fossil-scm.org/fossil/doc/trunk/www/rebaseharm.md
(21) By anonymous on 2020-07-09 16:58:40 in reply to 20 [link]
>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]
> 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.
(23) By John Rouillard (rouilj) on 2020-07-09 17:54:46 in reply to 18 updated by 23.1 [link]
I have also seen what Warren saw. Bisect between two trunk revisions ended up on revision committed to a branch. IIRC the branch was created and merged between the two initial trunk revisions. I would have been using default settings, so direct-only=on.
(23.1) By John Rouillard (rouilj) on 2020-07-09 17:59:38 edited from 23.0 in reply to 18 [link]
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]
> 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.
(25) By Andy Bradford (andybradford) on 2020-07-09 19:55:42 in reply to 3 [link]
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 session. 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. Andy
(26) By John Rouillard (rouilj) on 2020-07-09 20:06:06 in reply to 24 updated by 26.1 [link]
I think fixing Warren's test case would do it. 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
(26.1) By John Rouillard (rouilj) on 2020-07-09 20:34:34 edited from 26.0 in reply to 24 [link]
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
(27) By Richard Hipp (drh) on 2020-07-09 20:46:48 in reply to 1 [link]
> 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
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]
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]
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]
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]
You should modify line 609 as well (e.g. for `fossil bisect -h` or `fossil bisect fakecommand`).