All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <greg@kroah.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Arnd Bergmann <arnd@arndb.de>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Tomas Winkler <tomas.winkler@intel.com>
Subject: Re: linux-next: manual merge of the char-misc tree with Linus' tree
Date: Mon, 29 Jul 2013 18:38:08 -0700	[thread overview]
Message-ID: <20130730013808.GA5373@kroah.com> (raw)
In-Reply-To: <20130730102754.749949a5d53c54e4c6c72d53@canb.auug.org.au>

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@kroah.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

  reply	other threads:[~2013-07-30  1:38 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-29  5:01 linux-next: manual merge of the char-misc tree with Linus' tree Stephen Rothwell
2013-07-29 19:26 ` Greg KH
2013-07-29 22:16   ` Tomas Winkler
2013-07-29 22:25     ` Greg KH
2013-07-30  0:27   ` Stephen Rothwell
2013-07-30  1:38     ` Greg KH [this message]
  -- strict thread matches above, loose matches on Subject: below --
2020-07-27  7:46 Stephen Rothwell
2020-07-27  7:56 Stephen Rothwell
2021-08-27  6:49 Stephen Rothwell
2021-08-27 13:12 ` Greg KH
2021-08-27 16:24   ` Kalle Valo
2021-08-27 17:55     ` Manivannan Sadhasivam
2021-08-27 17:58   ` Manivannan Sadhasivam
2021-08-27 19:28     ` Greg KH
2021-08-28  7:27       ` Kalle Valo
2021-08-28  7:50         ` Greg KH
2021-08-28  9:51         ` Manivannan Sadhasivam

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=20130730013808.GA5373@kroah.com \
    --to=greg@kroah.com \
    --cc=arnd@arndb.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tomas.winkler@intel.com \
    /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.