Hi, > Gesendet: Mittwoch, 07. Juli 2021 um 17:03 Uhr > Von: "Chun-Kuang Hu" <chunkuang...@kernel.org>
> I think you have done many experiment [1] and you bisect between > 2e4773915223 (good) and be18cd1fcae2 (bad), and you are confused by > merge commit. > You may refer to [2] and it may help you to understand git bisect. thanks for confirming the strange behaviour is caused by merge-commit. that was i'm thinking about...if the merge-commit is not in actual bisect "tree" then all commits linked to it disappear. basicly i understand bisect (binary search - checkout a commit by splitting commits in 2 halfes and then splitting the bad half again and again till only 1 commit is detected). Imho the simplest solution may be flatten the tree (at least from good..HEAD) by rebasing, right? tried simple rebasing (from 5.12-rc2 sha1 ~17823 commits), but failed somewhere in usb-subsystem ;( i guess this happens if changes made in mergecommit...also tried with --rebase-merges and --preserve-merges but all do not make the history complete flat without conflicts set the merge itself as good is not a solution, as there are many merges and in one is the breaking commit other examples in your link do not change current history, only give tips for merging without these merge-commits i have git v2.25.1 btw. i have done many more experiments as public visible, reverting commits that may break (many i can't revert as they have depencies-code changed in same block after the commit to be reverted - e.g.) by reading commit-message, and adding some debug-messages in the drm_atomic_helper.c (drm_atomic_helper_wait_for_vblanks,drm_atomic_helper_wait_for_flip_done where the WARN() is done), but i have not yet nailed down the issue > [1] http://forum.banana-pi.org/t/bpi-r2-hdmi-4k-tv-fail/12307/4 > [2] > https://stackoverflow.com/questions/17267816/git-bisect-with-merged-commits
