linux-kernel - Re: linux-next: manual merge of the akpm tree with Linus' tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 10 Sep 2013 17:41:29 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	linux-next <linux-next@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Chinner <dchinner@...hat.com>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: linux-next: manual merge of the akpm tree with Linus' tree

On Tue, Sep 10, 2013 at 5:30 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>
> So, Andrew, you should be able to just about send those 375 patches to
> Linus (I know that there may be some fix folding to do before that) and
> have him apply them on top of v3.11-rc7-14-gfa8218d in a separate branch
> and then merge that branch.

That's how I have been doing Andrew's patch-bombs anyway, since I
started asking him what they were based on (they *usually* apply on
top of my current tip, but during the merge window so much happens
that it wasn't all that unusual that one or two patches didn't quite
apply). So these days I just always do a "git checkout -b akpm
<base-andrew-gives-me>" and apply the patches that way.

It's just that normally the base is within about six hours of my tip
anyway. This would be the first time it's way back.

But I much prefer having more of a merge of well-tested code over
having an easier merge of something that was rebased. That's
especially true if the rebasing ends up delaying me getting the
patches in the first place. I detest having merge windows where the
last few days are busy, I'd really much rather have a couple of days
with very little going on before doing the -rc1 (in the hope that rc1
actually ends up being pretty good).

> I have included the "git diff-tree --cc"
> output from my merge of that into linux-next yesterday.  Some of it is
> not applicable yet (since there are still some other outstanding trees),
> but it gives you some idea of how little the merge is a problem.

Yes. We actually seldom have real merge problems. The only really
annoying merges tend to be when somebody did something that isn't
really code-related, like sorting a big list of entries (Makefiles,
Kconfig files, device tree cleanups) and then both sides do a fair
amount of changes on their respective - and very different - sides.

The "multiple people worked on the same code" part is fairly unusual,
and particular if I know the code and can even compile it, it's all
fine.

              Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/