title: Changes made by merge commits not found by `git bisect` or `git log -S --all`
body: <p>I made a fix to a file, and committed it to my <code>git</code> repository.</p>
  
  <p>Some time later, I found that it had regressed. I wanted to know in which commit the fix had been taken out, so I tried <code>git bisect</code> and <code>git log --all -S TERM</code>, where "TERM" was a string added by my fix and which appeared nowhere else in the project.</p>
  
  <p>I found that <code>git bisect</code> blamed an unrelated commit, and I found that <code>git log --all -S TERM</code> only listed the commit in which I added TERM, and didn't list any commits as having removed it, even though it was no longer in the file at "master".</p>
  
  <p>After some manual searching, I found that there had been a merge commit between two branches. One branch had my fix and one did not. The merge author had picked the branch without my fix (strange, as there was no conflict in the file).</p>
  
  <p>My questions are:</p>
  
  <ul>
  <li>Why can <code>git bisect</code> not find merge changes? I don't see anything in the manpage about this limitation. Is there a different way to use it that will find the bad merge in the above scenario?</li>
  <li>Why does <code>git log --all -S TERM</code> not list the merge commit? The manpage says it lists commits which "introduce or remove an instance of ". Does that merge commit not remove my string? Is there a different way to use it that will find the bad merge in the above scenario?</li>
  <li>If <code>git bisect</code> and <code>git log -S</code> are useless in the above scenario, what is an efficient way to find the bad merge? It look me quite a long time to track down the change in question without these tools.</li>
  </ul>