From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, shawn.guo@freescale.com, kernel@pengutronix.de
Subject: Re: [PATCH 02/14] net/fec: release mem_region requested in probe in error path and remove
Date: Mon, 14 Feb 2011 09:25:25 +0100 [thread overview]
Message-ID: <20110214082525.GD13279@pengutronix.de> (raw)
In-Reply-To: <20110213.131531.57465973.davem@davemloft.net>
Hi David,
On Sun, Feb 13, 2011 at 01:15:31PM -0800, David Miller wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Date: Sun, 13 Feb 2011 22:07:09 +0100
> > On Fri, Feb 11, 2011 at 09:25:32PM -0800, David Miller wrote:
> >> I can't pull from that tree because it is _NOT_ based upon net-next-2.6
> >> and therefore brings in all kinds of commits not related to your work.
> > Sorry, I'm not used to the customs on netdev. I can rebase, but still I
> > wonder about the reason you cannot pull for. The only reason I can
> > imagine is that you fear unrelated breakage when taking these patches
> > that are already in Linus' tree. But if it's that, wouldn't it be great
> > the realize this breakage already now and not only during the next merge
> > window?
>
> My trees only merge in Linus's tree when absolutely necessary,
> to resolve conflicts or similar.
You don't merge Linus' tree, you merge mine that just happen to be based
on a newer version of Linus' tree. I'm sure Linus won't yell on you for
that. He only objects to merge directly from his tree, because the
result for him is an "empty" merge.
> We don't bring in unrelated changes into my tree, just for the
> sake of doing so.
>
> Otherwise Linus gets all of these ugly merge commits when he
> pulls from me, which are entirely unnecessary.
The result Linus gets if you pull my tree based on
v2.6.38-rc4-106-gd247852 (as it is now) is the same as if it were based
on v2.6.38-rc2-210-gc69b909 (which is the most recent commit net-next
currently bases on): my 14 patches and your merge commit. The reason for
that is that Linus already has the commits between
v2.6.38-rc2-210-gc69b909 and v2.6.38-rc4-106-gd247852. So this is really
only about when these commits enter *your* tree.
There are currently the following commits in Linus' tree that are used
by commits in net-next as parents:
c56eb8fb6dccb83d9fe62fd4dc00c834de9bc470
ff76015f3bdfbc482c723cb4f2559cef84d178ca (*)
c753796769e4fb0cd813b6e5801b3c01f4681d4f
0c21e3aaf6ae85bee804a325aa29c325209180fd (*)
e92427b289d252cfbd4cb5282d92f4ce1a5bb1fb (*)
1bae4ce27c9c90344f23c65ea6966c50ffeae2f5
7cc2edb83447775a34ed3bf9d29d8295a434b523 (*)
8f2771f2b85aea4d0f9a0137ad3b63d1173c0962 (*)
c4c93106741bbf61ecd05a2a835af8e3bf31c1bd (*)
c7c1806098752c1f46943d8db2c69aff07f5d4bc (*)
479600777bb588724d044815415f7d708d06644b (*)
1e6d93e45b231b3ae87c01902ede2315aacfe976 (*)
9b00b4157f7b3265de291ac8979a5f1611ce64ab
c69b90920a36b88ab0d649963d81355d865eeb05 (*)
and you don't want to take d247852 to this list because it's newer than
all these? How did you decide to take the newest in the list above and
why was that OK?
And as a last point let me note, that from Linus' POV the commits marked
with an asterisk above go into net-next by an empty merge.
Can you please reping me if you still consider that I should rebase my
tree for you to be able to merge it?
Best regards and thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
next prev parent reply other threads:[~2011-02-14 8:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-11 10:32 [PATCH 01/14] net/fec: no need to cast arguments for memcpy Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 02/14] net/fec: release mem_region requested in probe in error path and remove Uwe Kleine-König
2011-02-11 11:03 ` Uwe Kleine-König
2011-02-12 5:25 ` David Miller
2011-02-13 21:07 ` Uwe Kleine-König
2011-02-13 21:15 ` David Miller
2011-02-14 8:25 ` Uwe Kleine-König [this message]
2011-02-14 19:05 ` David Miller
2011-02-15 8:53 ` Uwe Kleine-König
2011-02-15 18:31 ` David Miller
2011-02-15 20:00 ` Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 03/14] net/fec: don't free an irq that failed to be requested Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 04/14] net/fec: no need to check for validity of ndev in suspend and resume Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 05/14] net/fec: no need to memzero private data Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 06/14] net/fec: put the ioremap cookie immediately into a void __iomem pointer Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 07/14] net/fec: consolidate all i.MX options to CONFIG_ARM Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 08/14] net/fec: add phy_stop to fec_enet_close Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 09/14] net/fec: consistenly name struct net_device pointers "ndev" Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 10/14] net/fec: some whitespace cleanup Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 11/14] net/fec: reorder functions a bit allows removing forward declarations Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 12/14] net/fec: provide device for dma functions and matching sizes for map and unmap Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 13/14] net/fec: postpone unsetting driver data until the hardware is stopped Uwe Kleine-König
2011-02-11 10:32 ` [PATCH 14/14] net/fec: enable flow control and length check on enet-mac Uwe Kleine-König
2011-02-17 22:32 ` [PATCH 15/14] net/fec: remove unused driver data Uwe Kleine-König
2011-02-22 18:16 ` David Miller
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=20110214082525.GD13279@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=davem@davemloft.net \
--cc=kernel@pengutronix.de \
--cc=netdev@vger.kernel.org \
--cc=shawn.guo@freescale.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).