From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49281) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buedq-0005cu-0F for qemu-devel@nongnu.org; Thu, 13 Oct 2016 07:57:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1buedp-0002ts-4s for qemu-devel@nongnu.org; Thu, 13 Oct 2016 07:57:41 -0400 Received: from mail-vk0-x230.google.com ([2607:f8b0:400c:c05::230]:36805) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1buedo-0002tF-VB for qemu-devel@nongnu.org; Thu, 13 Oct 2016 07:57:41 -0400 Received: by mail-vk0-x230.google.com with SMTP id 2so74446127vkb.3 for ; Thu, 13 Oct 2016 04:57:40 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1476335734-29831-1-git-send-email-david@gibson.dropbear.id.au> From: Peter Maydell Date: Thu, 13 Oct 2016 12:57:19 +0100 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PULL 0/4] ppc patches for qemu-2.7 stable branch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Gibson Cc: qemu-stable , Thomas Huth , QEMU Developers , Alexander Graf , "qemu-ppc@nongnu.org" , Anton Blanchard On 13 October 2016 at 12:54, Peter Maydell wrote: > On 13 October 2016 at 06:15, David Gibson wrote: >> The following changes since commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a: >> >> Update version for v2.7.0 release (2016-09-02 13:44:11 +0100) >> >> are available in the git repository at: >> >> git://github.com/dgibson/qemu.git tags/ppc-for-2.7-20161013 >> >> for you to fetch changes up to 2e68f28854f0120c9a938a61b64aaf1eaecb162b: >> >> ppc: Check the availability of transactional memory (2016-10-13 12:58:06 +1100) > > Applied to master, thanks. (I hope that was what you had in mind; > if not we'll have to unwind stuff somehow...) unwind> looking more closely, there's no actual diff between HEAD now and what it was, so the merge commit is a no-op of sorts. Hopefully it doesn't cause any problems. More generally, we need to come up with something for distinguishing PULL requests not for master, because my current workflow basically says "anything that says 'for you to fetch changes up to' will get merged into master... thanks -- PMM