On Wed, Mar 02, 2016 at 09:24:46AM +0800, Qu Wenruo wrote: > > > Chris Mason wrote on 2016/03/01 20:11 -0500: > >On Wed, Mar 02, 2016 at 08:48:06AM +0800, Qu Wenruo wrote: > >> > >> > >>Chris Mason wrote on 2016/03/01 11:06 -0500: > >>>On Tue, Mar 01, 2016 at 10:20:26AM +0100, David Sterba wrote: > >>>>Hi Chris, > >>>> > >>>>On Fri, Feb 26, 2016 at 01:22:00PM +0000, fdmanana@xxxxxxxxxx wrote: > >>>>>The following changes since commit 0fcb760afa6103419800674e22fb7f4de1f9670b: > >>>>> > >>>>> Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux into for-linus-4.6 (2016-02-24 10:21:44 -0800) > >>>>> > >>>>>are available in the git repository at: > >>>>> > >>>>> git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux.git integration-4.6 > >>>>> > >>>>>for you to fetch changes up to 97c86c11a5cb9839609a9df195e998c3312e68b0: > >>>>> > >>>>> Btrfs: do not collect ordered extents when logging that inode exists (2016-02-26 04:28:15 +0000) > >>>> > >>>>Filipe's branch is based on some integration snapshot that contains the > >>>>'delete device by id' patchset that was removed from the 4.6 queue. > >>>> > >>>>Your branch 'next' merges it back again through Filipe's tree, besides > >>>>that the merge commits of the topic branches in my for-next appear > >>>>twice. While the duplicated commits are only an esthetic issue, the > >>>>extra branch bothers me. > >>>> > >>>>I don't see a nice way how to avoid rebases in this cases. My suggestion > >>>>is that Filipe rebases the branch on my for-chris that could have been > >>>>an integration at some point. > >>>> > >>>>As we're merging our branches that way for the first time I'd like to > >>>>find the workflow also for the next dev cycles so I'm open to other > >>>>suggestions. > >>> > >>>Ugh, thanks Dave I missed this. I'll rebase Filipe on top of your > >>>branch. The easiest way to avoid it in general is to only base trees on > >>>top of things already in Linus' tree. If there are specific > >>>dependencies we can work it out on a case by case basis, but the merge > >>>conflicts are almost always trivial. > >>> > >>>-chris > >> > >>Although off-topic, but do we need to rebase all sent pull to the new > >>integration-4.6? > > > >Unless there are huge conflicts, it's actually much easier to base > >against a recent v4.5-rcN. That way if we do have to rebase the > >integration branch, it doesn't mess up your pull request. > > > >If there are small conflicts, I can just deal with them when I pull. > >For bigger conflicts, I'll either rebase on top of integration as > >individual patches, or ask for help ;) > > Thanks for the tip. > Seems git can handle them well. (yeah, no more patch bombing ) Please keep patch bombing ;) It's the best way to get things reviewed. Besides, if people didn't like email, they would have found different jobs long ago ;) -chris -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
