Bartosz Baranowski <bbaranow@xxxxxxxxxx> writes: > Depending how you end bisecting, result/report is either one liner or > dumps commit information: > > > $ git bisect bad > 77c044d8d66f9f9bebdb805853409e920e537d59 is the first bad commit > commit 77c044d8d66f9f9bebdb805853409e920e537d59 > Author: XXXX > Date: Tue Jan 22 09:24:02 2019 -0500 > > ISSUE-11626 Bad fish in the sea of comment > > :040000 040000 ef2280aa5f7e0c23f8750c43a0bf05c0a9639fe3 > f63bea979784cade7dffd653d939f665ff6a53b7 M clustering > :040000 040000 6f4667c819106f6e9ddbb902253862212a2558f5 > 4d8c4dc85872c0665eb77957a6fd69c49c173188 M triton > :040000 040000 0400075b3d5f7cb9e68683b25b8ede93fb1b293b > 35ba4c831c4834f9ce612e394621dde382bc72f1 M web-common > > vs > > > git bisect good > 3a9388eef42efc87c78ce22158d55e69a278b4eb is the first bad commit > > git --version > git version 2.14.1 Are you sure (and if so how did you reach that conclusion) that the above difference comes from the last 'bad' vs 'good' you finished, and not comes from the difference between 77c044d8 vs 3a9388ee? At the end of the bisection session, bisect.c::show_diff_tree() is called on that "culprit" commit. Is it possible that 3a9388ee is a simple and trivial merge that does not have anything worth reporting for "git diff-tree"?
