On Fri, Mar 02, 2012 at 09:03:01PM +0000, Love, Robert W wrote: > On 03/02/2012 12:44 PM, Neil Horman wrote: > > On Fri, Mar 02, 2012 at 08:29:18PM +0000, Love, Robert W wrote: > >> Hello everyone, > >> > >> I rebased fcoe-next to be based on the latest scsi-misc (as of an hour > >> ago). Please rebase any down stream repositories as needed. I > >> reviewed/tested/committed all of the outstanding patches. There were two > >> patches I had to fix whitespace issues on. > >> > >> I also committed all outstanding user space patches. > >> > >> Please let me know if you have any issues with these (or any of the > >> other) repositories. > >> > >> Thanks, //Rob > > Robert, can I ask why you do rebasing at all here? It seems like you should > > just be pulling from scsi-misc periodically (preuming thats where fcoe-next > > pull > > requests go), and it would all just stay in-line (and we wouldn't have to > > re-clone our trees). > Only so that "our patches" stay on top. If I were to 'pull', I believe > it will bury our patches in the patch history and then I will have a > hard time finding our patches when I go to create the series to send to > scsi-misc. James wants patches on the list, not a pull request. > Ah, I see, yes that does make things somewhat difficult.
> I'd prefer not to 'rebase' too. It's really disruptive, in multiple > ways, so I'm definately up for suggestions. Do you know of a way to > cleanly get "our patches" if I were to start 'pull'ing instead of > 'rebase'ing? I haven't played around with this stuff much. We discussed > it a few years ago, but I haven't revisited the rebase/merge issue in a > long time. Yeah, normally subtrees operate under the assumption that they will only take commits from contributors and pass them up the maintainer chain. Needing to pull in other changes from your upstream tree constantly sort of throws a monkey wrench into your workflow. > > Also, aside from my problems creating the series to send to linux-scsi, > our changes simply won't be as visible in 'git log' or gitweb. It's kind > of nice just seeing what we've done on the top of the history all the time. > Yes, seeing your git history is important. > FYI, I try to keep fcoe-next based on scsi-misc, but sometimes if > there's a bug in scsi-misc that's blocking a lot of people, but is fixed > in Linus' tree, I might rebase to Linus' tree to get the fix. I want to > avoid that case if I can, but I'll notify the list if I do it. I just > don't want people blocked for a month because scsi-misc isn't moving. > My suggestion would probably be to use git cherry-pick, if the blocking patches are small, you can pull them into your tree without rebasing, and cherry-pick lets you easily identify them as cherry-picks, so you can skip them when you generate series to post to scsi-misc. If the patches you want to grab are larger, you can pick them, and then squash them down into a single commit before you push to the public tree. You're history is still intermingled with other patches from upstream, but it would be small and arguably manageable. Are these out-of-line pulls from upstream frequent? It seems like they shouldn't be (although I understand that with a merge, you get a bunch of extra stuff you don't always want, cherry-pick helps with that). I'll do some playing and see if I can't come up with an even better solution Thanks Neil > Thanks, //Rob > > > Regards > > Neil > > > >> _______________________________________________ > >> devel mailing list > >> [email protected] > >> https://lists.open-fcoe.org/mailman/listinfo/devel > >> > _______________________________________________ devel mailing list [email protected] https://lists.open-fcoe.org/mailman/listinfo/devel
