[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110922081140.GH17169@n2100.arm.linux.org.uk>
Date: Thu, 22 Sep 2011 09:11:40 +0100
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Olof Johansson <olof@...om.net>
Cc: Stephen Warren <swarren@...dia.com>,
Colin Cross <ccross@...roid.com>,
Erik Gilling <konkers@...roid.com>,
Grant Likely <grant.likely@...retlab.ca>,
Chris Ball <cjb@...top.org>, linux-tegra@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-mmc@...r.kernel.org
Subject: Re: [PATCH 1/3] arm/tegra: Move EN_VDD_1V05_GPIO to board-harmony.h
On Wed, Sep 21, 2011 at 01:16:49PM -0700, Olof Johansson wrote:
> Works for me. Or I could stage it in a topic branch that would be
> merged after Russell's GPIO tree.
Holding stuff off from being merged doesn't work. If you have the
following commit structure:
A---...-----M1-B-C-M2
+---A1-B1-C1' /
+-A2-B2-C2-------'
Now, lets say A2 depends on C1. Merely delaying the stuff so that M2
happens after M1 is insufficient to ensure git state doesn't break.
When bisecting, its entirely possible that the bisect algorithm may
chose B2 as a potential test candidate. At that point you end up with
A2, but without C1.
The only way to solve this is to have A2 following on from C1 - which
of course requires A1..C1 to be declared stable and either pulled into
your local tree or for A2..C2 to be submitted to the same tree which
A1..C1 are already in.
--
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/
Powered by blists - more mailing lists