On Fri, 28 Oct 2011, Greg KH wrote: > On Fri, Oct 28, 2011 at 11:39:42AM -0400, Alan Stern wrote: > > Greg: > > > > In your USB repository you keep two main branches: usb-linus and > > usb-next. As I understand it, patches that contain new development get > > added to usb-next (which doesn't get pushed to Linus until the next > > merge window), whereas patches fixing bugs in the upcoming release get > > added to usb-linus (which gets pushed to Linus every week or so). > > That is correct. > > > Doesn't it make more sense to add bug-fix patches to both branches? > > Not doing this increases the likelihood of conflicts, because new > > development could well need to touch code that just had some sort of > > fix applied. > > That's true, if you think a specific patch should be applied to both, I don't have any specific patches in mind; this was just thinking in general. Is there any good reason for keeping the two sets of patches separated? > I'll be glad to do so. Generally when I test, I test with a merge of > both trees together, as that's the true end-result for what linux-next > is showing, and what the next release really will have in it. > > Almost always there is not any conflicts, with a few minor exceptions. > > For example, for the 3.2 merge window, there were no conflicts, only my > tty tree had a conflict, as did my staging tree, but both of them were > trivial to resolve, infact, linux-next warned me about them before I > even realized they were there. I've been trying to figure out a way to reproduce what you used to have, where the gregkh-usb-*.patch file would apply on top of the current -rc tree. It looks like the only equivalent using git is to merge the two branches, as you say. Alan Stern -- 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
