On Thu, Dec 01, 2011 at 01:04:13PM +0000, Mark Brown wrote: > 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. ok, fair enough. -- balbi
Attachment:
signature.asc
Description: Digital signature
