[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231025110918.5417ab87@canb.auug.org.au>
Date: Wed, 25 Oct 2023 11:09:18 +1100
From: Stephen Rothwell <sfr@...b.auug.org.au>
To: David Sterba <dsterba@...e.cz>
Cc: Christian Brauner <brauner@...nel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>
Subject: Re: linux-next: manual merge of the vfs-brauner tree with the btrfs
tree
Hi David,
On Tue, 24 Oct 2023 17:32:29 +0200 David Sterba <dsterba@...e.cz> wrote:
>
> On Tue, Oct 24, 2023 at 08:25:43AM +1100, Stephen Rothwell wrote:
> >
> > On Mon, 23 Oct 2023 19:55:13 +0200 David Sterba <dsterba@...e.cz> wrote:
> > >
> > > I have updated my for-next branch again, sorry (top commit 1a4dc97c883a4f763cbaf50).
> > > There are some fixes I don't want to miss from the 6.7 pull request.
> > > There should be minimal change to the VFS tree conflict resolution so
> > > the diff should be reusable.
> >
> > So, why did you not just merge in v6.6-rc7 (or better yet, the branch
> > that contains the fix(es) that Linus merged) and then apply your new
> > commits on top of that? All the commits that were in the btrfs tree
> > have been rebased unchanged.
>
> I don't back merge Linus' branches nor the fixes that I send, that's
> against what I understand is the recommended practice. The development
> queue gets rebased on top of the rc, in that way it's clean and
> eventually drops patches sent independently merged to the master branch.
Please read Documentation/maintainer/rebasing-and-merging.rst
--
Cheers,
Stephen Rothwell
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists