linux-kernel - Re: linux-next: manual merge of the char-misc 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] [day] [month] [year] [list]

Message-ID: <20130730013808.GA5373@kroah.com>
Date:	Mon, 29 Jul 2013 18:38:08 -0700
From:	Greg KH <greg@...ah.com>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Arnd Bergmann <arnd@...db.de>, linux-next@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Tomas Winkler <tomas.winkler@...el.com>
Subject: Re: linux-next: manual merge of the char-misc tree with Linus' tree

On Tue, Jul 30, 2013 at 10:27:54AM +1000, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Mon, 29 Jul 2013 12:26:49 -0700 Greg KH <greg@...ah.com> wrote:
> >
> > On Mon, Jul 29, 2013 at 03:01:29PM +1000, Stephen Rothwell wrote:
> > > 
> > > Today's linux-next merge of the char-misc tree got a conflict in
> > > drivers/misc/mei/init.c between commit 99f22c4ef24c ("mei: don't have to
> > > clean the state on power up") from Linus' tree and commit b950ac1dabfc
> > > ("mei: don't get stuck in select during reset") from the char-misc tree.
> > > 
> > > (Unrelated white space changes are a pest :-()
> > > 
> > > I fixed it up (see below) and can carry the fix as necessary (no action
> > > is required).
> > 
> > Thanks, I've merged the char-misc-next branch into 3.11-rc3, so this
> > merge problem should no longer be there.
> 
> Unfortunately, I think this is exactly the sort of back merge that Linus
> hates.  He and I are quite capable of coping with relatively complex
> merge conflicts, so ones like this are really not a problem (and "git
> rerere" takes care of it once I have resolved it the first time).  That
> is why I added "no action is required" to my notification messages.
> These messages are really more "this is what I did, please tell me if I
> did something wrong", not "please fix this up"  (I know this message from
> me has changed over time - we can all learn, even us oldies :-))
> 
> Also, if you are doing a merge of fixes that you have submitted to
> Linus, it is probably better to merge your fixes branch rather that
> Linus' tree after he has merged it - that way you are not dragging
> irrelevant stuff from Linus' tree into yours and complicating the git
> history/bisecting so much.
> 
> Of course, if you need something from Linus' tree that someone else put
> there to continue development, then you need to back merge Linus' tree,
> but after rc2 or 3 that should be rare.  And, of course, such a back
> merge needs a good changelog explaining exactly why it was done.

I usually want those fixes from the rcs and merge at that point in time
every other -rc release or so, just to make it much easier for me to
test with, and to pick in the patches I've sent to Linus.

Yes, I could just suck in my fixes branch, but I would be stuck with
trees based on -rc1, which is almost always a pain to test with.

I'm not doing "merges every week", and have been doing it this way for a
few years now with no complaints.  The -rc point in time is a good place
to sync up with it seems.

thanks,

greg k-h
--
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/