On Fri, Oct 28, 2011 at 02:41:47PM -0400, Alan Stern wrote: > 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. Yes, that's the way. Hopefully, it's even easier for you to do this now, than before. I'd recommend (and this is what I do on my machines), doing something like this: - clone the usb.git tree - create the usb-next tracking branch: git checkout -t -b usb-next origin/usb-next - create the usb-linus tracking branch: git checkout -t -b usb-linus origin/usb-linus - checkout one of them: git checkout usb-linus - create your branch to do stuff on: git checkout -b work Now you have a branch called "work" that was based off of usb-linus. Update things so that you have a merge of the two: - git checkout work - git merge usb-linus - git merge usb-next hopefully there were no conflicts, and now you have the merge of the two. As time goes on, you can just live on this work branch, making new changes and sending them to me. When I update my branches, you can update yours: - git checkout usb-linus - git pull - git checkout usb-next - git pull [note, I think there's an easier way to fetch the updates from "upstream" and update the branches, but I can't remember it at the moment.] Then check your branch out again: - git checkout work and merge: - git merge usb-linus - git merge usb-next and all should be good. Does that help out? greg k-h -- 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
