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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.