On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote: > For bisecting trunk a merge would be a single commit, right? So I could see > value in preserving a patch series where individual steps might introduce > temporary issues as a branch merge (after rebasing) so the series is visible > but not when bisecting (by default). It would also make the series > relatedness obvious and avoids splitting it with a commit race (if that is > possible with git).
"git bisect" actually goes all the way down the rabbit hole, it tries to find the first bad commit in the range you marked as starting as "good", ending as "bad". It is pretty confusing to do if there are many merges, especially if many commits end up not building at all. But you can always "git bisect skip" stuff (it just eats time, and it hampers automated bisecting). The really nasty cases are when the code does build, but fails for unrelated reasons. We require every commit to be individually tested, and if we *do* allow merges, that should still be done imo. Which again makes merging less useful: if you are going to rebase your branch anyway (to fix simple stuff), why not rebase it onto trunk! > IMHO exact workflow for merging a patch series as opposed to a single patch > should be documented. Yes. It isn't actually documented in so many words for what we do now, either, but it would be good to have. Segher
