3 ms·
One problem that I've had when bisecting is moving back in time towards code where resolved bugs still exist - masking the new bug. The solution that I found w
by yarg 4y ago
One problem that I've had when bisecting is moving back in time towards code where resolved bugs still exist - masking the new bug.
The solution that I found was fixing the bug at the commit that created it, squashing, and then rebasing on top.
But it's far from ideal, and completely non-viable if there's heavy use of the repo from other developers.
- adrianmsmith 4y agoAnd also not ideal if your bugfix accidentally introduces new bugs and you later realise you want to go back to the version before the bugfix, or see what the code change of the bugfix was.
- yarg 4y agoYou could keep a zero bug branch and merge back and forth between chronological.
- tomjakubowski 4y agoahh… zero bug branch commit 011bf12e41fea384c06873505b25cd44f995926d (HEAD -> main) Author: Tom Jakubowski <tom@crystae.net> Date: Sat Aug 6 09:27:05 2022 -0700 initial commit diff --git a/README b/README new file mode 100644 index 0000000..3b18e51 --- /dev/null +++ b/README @@ -0,0 +1 @@ +hello world