On Thu, Dec 01, 2011 at 12:33:05PM +0200, Felipe Balbi wrote: > On Wed, Nov 30, 2011 at 02:05:18PM +0000, Mark Brown wrote: > > Clearly someone is going to have do the merge, the point is that this > > should be done as part of pulling the changes rather than the person > > sending the pull request. This gives the person doing the pull more > > visibility of what's going on and in general there's going to have to > > be a further merge anyway as a result of other changes in the master > > tree. > that works fine when you have everything on one single branch, but I > keep multiple branches for different drivers/frameworks: one for the > DWC3 driver, one for MUSB, one for HCI, one for transceivers, one for > gadget framework, and so on. If I'm not supposed to do any merges, then > I'll have to send multiple pull requests which is just a waste of time. That's a bit different to the case I was mentioning above where you're merging upstream back into your tree before sending, in this case it depends partly on the maintainer's preferences. Many prefer to be able to take a decision per topic on what they merge as this allows them to pull only part of what you're sending and makes the chunks being checked a bit smaller (really a similar line of thinking to the idea of splitting up patches). Other mantainers don't care, and the decision may depend on what the pull request is. > I don't see why this fear of merge commits, really. It's not that merges are bad (almost all pull requests result in merges after all), it's a visbility thing. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
