Bisectable does not work well with segfaults, committable is OK #14
Labels
bisectable
Issues related to Bisectable bot
Comments
AlexDaniel
added a commit
that referenced
this issue
Sep 18, 2016
The main purpose of this commit was to make bisectable understand segfaults (and other signals). As it required a major rework in the logic, I've also changed the terms (“good” → “old”, “bad” → “new”) and changed the messages slightly to make it more consistent and less wordy (although the number of messages sent by bisectable has increased slightly). == Issue #14 (search for segfaults) Now there are three types of bisection in total: * By signal (new) * By exit code * By output Previously we treated non-zero exit code on old (or “good”) revision as a special case, but not anymore. Initially bisectable was supposed to be a transparent layer to ｢git bisect run｣ and users were expected to write “proper” queries where exit code on old (or “good”) revision is 0. If exit code was non-zero, bisectable was smart enough to understand this and make corrections so that ｢git bisect run｣ does not get confused. The code assumed that you were looking for a revision that has exit code zero (and that's where the idea of “inverted logic” comes from). As now I realize that people do not really care how ｢git bisect run｣ is supposed to work and just want bisectable to DWIM, I am no longer married to the idea of making it very git-like. This is especially true after commit 540aba6, since we no longer ask git to do everything for us and instead perform the bisection completely in perl 6. So to be consistent with other modes, the idea of “inverted logic” had to be thrown away. Now any change from behavior on old (or “good”) revision is considered new (or “bad”). This means that if exit code on old revision is 5, exit code 42 will be considered new (previously only 0 would have been considered new). Same idea applies if you bisect by signal or output. Also, it now always prints how bisection is performed. Previously “bisecting by exit code” was not being printed because this was supposed to be the most common mode and everything else was considered as a deviation. Now all modes are equal. == Issue #28 (new terms) Newer versions of git also support terms “old” and “new” instead of “good” and “bad”. This is what we now default to (old terms are still supported). These new terms are much clearer, especially in cases when “bad” is actually “good” (e.g. when you are trying to find when something was fixed, instead of trying to find when something got broken). == Some code refactoring * run-bisect method was significantly simplified. This is mainly due to the introduction of RevisionType enum which is now returned from test-commit (instead of returning some virtual exit code). * gather/take instead of appending to a Str. This gets rid of some visual code clutter (e.g. “\n” where it could be added automatically). * exit code/signal/output are now passed as named parameters instead of being passed in one variable (which was actually buggy in cases when the output was numeric). This was a pre-540aba6 fossil (which shouldn't've existed in the first place, but oh well…) * Do not print the operation mode if there was some git failure (makes more sense given that bisection process does not really start if there is a problem). * New tiny signal-to-text helper sub to reduce code repetition (it should probably be moved to Whateverable.pm6). * Now there is no need to save the output into a file, we can just keep it as a Str and pass it around (another pre-540aba6 fossil). Congratulations! You've just read a blog post in a commit message.
|
Implemented in ca77fb5 |
AlexDaniel
added
the
testneeded
AlexDaniel
removed
the
testneeded
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
See this: http://irclog.perlgeek.de/perl6-dev/2016-07-28#i_12928310
The text was updated successfully, but these errors were encountered: