8

Let's say I have these revisions:

  • rev 1 introduces bug #1
  • rev 2 possibly introduces bug #2
  • rev 3 possibly introduces bug #2
  • rev 4 possibly introduces bug #2
  • rev 5 fixes bug #1

To 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?

silverwind
  • 3,296
  • 29
  • 31
  • 4
    see `Automatically bisect with temporary modifications` in the bisect documentation. – torek Apr 29 '15 at 01:10
  • 3
    Adding a link to the docs example section that Torek mentions: https://git-scm.com/docs/git-bisect#_examples @torek If you posted that link as an answer, I'd vote for it :) – ncoghlan Mar 12 '18 at 12:15
  • 1
    @ncoghlan: I'd basically just be reproducing the man-page example (SO answers aren't supposed to be just-a-link)... – torek Mar 12 '18 at 15:09

2 Answers2

4

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]
silverwind
  • 3,296
  • 29
  • 31
  • this sounds ok but is it possible that the fix could be amended into the last commit to avoid doing tis step by step? – Jorch914 May 07 '15 at 18:54
  • 1
    For automated bisection, combine `git cherry-pick --no-commit` (instead of `git-merge`) with the `hot-fix` example mentioned in the comments on the question. – ncoghlan Mar 12 '18 at 23:26
4

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.

Luke
  • 121
  • 1
  • 3