Menu
Let's say I have these revisions:
rev 1 introduces bug #1rev 2 possibly introduces bug #2rev 3 possibly introduces bug #2rev 4 possibly introduces bug #2rev 5 fixes bug #1To verify where bug #2 occured, bug #1 needs to be fixed.
Can the revision where bug #2 first occured be determined during a single git bisect run, possibly through manually appling the rev 5 patch on each bisect step? Would manually patching interfere a bisect?
570
Use Git Bisect to find the commit in which line 2 is changed from 'b = 20' to 'b = 0.00000'. Remove the bad commit by using Git Revert. Leave the commit message as is. Push to the remote repository.
Bisect reset (A new git bisect start will also do that, as it cleans up the old bisection state.) For example, git bisect reset HEAD will leave you on the current bisection commit and avoid switching commits at all, while git bisect reset bisect/bad will check out the first bad revision.
To track down a broken commit, git gives us a very handy tool called git bisect . Git bisect does a binary search to find the broken commit.
After actually reading the docs, something like this might work (per bisect step):
git cherry-pick [patch-rev]
git reset --hard
git bisect [good/bad]
When you reach the region that requires the hot-fix patch(rev 5 in your ex.), just run:
git cherry-pick --no-commit hot-fix
Then continue bisecting normally.
39
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
