On 29/12/2019 12:15, Segher Boessenkool wrote: > 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 >
We agreed that for changes in our current workflow practices we'd defer that until *after* we'd switched to git; so this is getting off topic. On the other hand, we do need to sort out what we do with existing merge history, as that forms part of the conversion. Can we stick to what's relevant, please, at least in this thread? R.
