> > This branch has a merge in it, due to conflicts with the Intel drm tree > > you already pulled. I've asked Eric to not send you direct pulls, he > > mentioned you said he should, but it really screws over my tree. I don't > > mind direct pulls outside the merge window as it usually smaller bug > > fixes, but during the merge window the chances of it getting messy like > > this tree has become just increase. > > Qutie frankly, I don't like how you always rebased patches, so I'd _much_ > rather see direct pulls than the alternative. And I can handle most merge > issues, and will ask submaintainers to merge for me only if it gets really > complicated. > > If this encourages people to keep DRI drivers more modular and > independent, that's all good.
That's fine you only requested I stop rebasing Eric's tree since the last merge window, I haven't had to pull it since then to send to you. This merge there was 3 conflicts, I think they were mostly trivial, however there was also a warning fix in i915 for a return type not checked that no-one else picked up on. I'm still awaiting Documentation/linus-rules-for-git-trees.txt. I'm sure every other maintainer who is just guessing what the rules are would appreciate it as well. We don't all have the time of Ingo to do a branch per patch with a scary octopus merge every few weeks. My plans from now on are just to send you non-linear trees, whenever I merge a patch into my next tree thats when it stays in there, I'll pull Eric's tree directly into my tree and then I'll send the results, I thought we cared about a clean merge history but as I said without some document in the kernel tree I've up until now had no real idea what you wanted. Dave. ------------------------------------------------------------------------------ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
