From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Chris Mason <clm@fb.com>, <dsterba@suse.cz>,
<fdmanana@kernel.org>, <linux-btrfs@vger.kernel.org>
Subject: Re: [GIT PULL] Btrfs fixes for 4.6
Date: Wed, 2 Mar 2016 08:48:06 +0800 [thread overview]
Message-ID: <56D63846.7090204@cn.fujitsu.com> (raw)
In-Reply-To: <20160301160650.fjyyrnf6qfcekgr6@floor.thefacebook.com>
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?
Yes, I mean the in-band de-dup patchset. (If it is going to be merged)
Thanks,
Qu
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2016-03-02 0:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 13:22 [GIT PULL] Btrfs fixes for 4.6 fdmanana
2016-03-01 9:20 ` David Sterba
2016-03-01 16:06 ` Chris Mason
2016-03-02 0:48 ` Qu Wenruo [this message]
2016-03-02 1:11 ` Chris Mason
2016-03-02 1:24 ` Qu Wenruo
2016-03-02 1:34 ` Chris Mason
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56D63846.7090204@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=clm@fb.com \
--cc=dsterba@suse.cz \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).