Re: [GIT PULL] Btrfs fixes for 4.6

[Chris Mason <clm@fb.com>]

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@kernel.org 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