0

I'm trying to avoid writing my own bisect tool here, but I thought I'd check here first.

Basically, I want to bisect only commits listed in git log --merges (i.e. I want to figure out which PR introduced a problem). However, git bisect seems to use all commits, not just PR merge commits. This is problematic, because testing whether the commit is good or bad is extremely onerous for anything but PR merge commits (which are pre-built in an artifactory).

Using git skip to cull non merge commits as suggested here is sub-optimal and not a true binary search of merge commits. For example, I used the git skip approach and this is the path bisect took (this is a list of merge commits, asterisk is problem merge commit, numbers are the path bisect took):

  6e473285b96b62d6f4d95b36b23099f1ac55bdc9
  7ef96ab33ca8ca1b0a936d3cb40afec69637b289
* fa56ec958635e1e4db655e7768597ebefb475627 4 
  7a2e6c2087d58403f0801178f58ee8478f8e575b 5 DONE, bad merge commit is fa56ec9
  a86c9e98f94a4c619ef2b0a987886c02397d8eda 3 
  466469d32acf50769dc2db8bb97ce898e07a1018
  fb9c84883b726e733631f7b46fa0074e7a685ffc
  dd5d343188a27848d7e563b458cdef4bb295e321 2
  918d903a543402e6acc9eba9d5f38f1ebff6329d
  dfffce27f96415189775286adfd4222aba72e761
  07ceb2ba9620bbf4360b9b461c587ed2d18ccabb
  31813de9c7efb6765a18657f235379d1049fbbea
  460a2f8061e4d1b1d6faf81e0f8b3e1af011f096 1 <-- bisect starting at sub-optimal commit because of git skip
  93d5da46d01f180c8b4d36c8b302bf0763a79955
  fd01fd2381ec47954fc37488df9fbe773e9cf68a
  2cf6e83fc63d95c5ab50a4c23be12188b2983910
  b7bd87fde16d9905b4d368a605b7678184577b0e
  6e473285b96b62d6f4d95b36b23099f1ac55bdc9
  7ef96ab33ca8ca1b0a936d3cb40afec69637b289
* fa56ec958635e1e4db655e7768597ebefb475627 3
  7a2e6c2087d58403f0801178f58ee8478f8e575b 4 DONE
  a86c9e98f94a4c619ef2b0a987886c02397d8eda 2
  466469d32acf50769dc2db8bb97ce898e07a1018
  fb9c84883b726e733631f7b46fa0074e7a685ffc
  dd5d343188a27848d7e563b458cdef4bb295e321
  918d903a543402e6acc9eba9d5f38f1ebff6329d 1 <-- optimal starting commit
  dfffce27f96415189775286adfd4222aba72e761
  07ceb2ba9620bbf4360b9b461c587ed2d18ccabb
  31813de9c7efb6765a18657f235379d1049fbbea
  460a2f8061e4d1b1d6faf81e0f8b3e1af011f096
  93d5da46d01f180c8b4d36c8b302bf0763a79955
  fd01fd2381ec47954fc37488df9fbe773e9cf68a
  2cf6e83fc63d95c5ab50a4c23be12188b2983910
  b7bd87fde16d9905b4d368a605b7678184577b0e

I can generate a list of commits I want to bisect with git log --merges, but is it possible to somehow feed this list to git bisect so it can optimally bisect or am I out of luck?

Gillespie
  • 5,780
  • 3
  • 32
  • 54
  • 1
    bisect needs to inspect (and respect) the graph topology. You have linearized the commits here without showing the underlying topology, so it's not clear whether Git's testing *was* sub-optimal, but I think the short answer to your question is just "no, you can't do that". I'd leave it open for a while to see if someone knows a way that you *can* do that though. – torek May 08 '20 at 00:14

1 Answers1

0

No, Git doesn't provide an option to bisect only merge commits. git bisect is designed to find the actual commit that is problematic, not only one of a set. Therefore, it doesn't let you search only merges. A single merge can introduce hundreds of potentially relevant changes that might have caused the problem (think the Linux kernel) and so in many cases pinpointing a single merge doesn't tell you much.

In this case, the only downside here is that you're having to search one more commit, which overall is not that painful. Using either the approach you've used or a script that exits 125 to skip non-merge commits that's used with git bisect run are the best you can do in this case, and I personally would not consider the downsides (with a small number of extra iterations) so terrible that it's worth writing your own tool.

bk2204
  • 64,793
  • 6
  • 84
  • 100