From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55323) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws62w-0001oB-Ew for qemu-devel@nongnu.org; Wed, 04 Jun 2014 03:55:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ws62p-0003BA-H1 for qemu-devel@nongnu.org; Wed, 04 Jun 2014 03:55:42 -0400 Received: from static.88-198-71-155.clients.your-server.de ([88.198.71.155]:51894 helo=socrates.bennee.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ws62p-0003Ag-4W for qemu-devel@nongnu.org; Wed, 04 Jun 2014 03:55:35 -0400 From: Alex Bennée References: <1401434911-26992-1-git-send-email-edgar.iglesias@gmail.com> <1401434911-26992-7-git-send-email-edgar.iglesias@gmail.com> <87lhtes35w.fsf@linaro.org> <20140604023346.GD3378@toto> In-reply-to: <20140604023346.GD3378@toto> Date: Wed, 04 Jun 2014 08:55:30 +0100 Message-ID: <874n01rtvx.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v1 06/16] target-arm: Add FAR_EL2 and 3 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Edgar E. Iglesias" Cc: peter.maydell@linaro.org, peter.crosthwaite@xilinx.com, rob.herring@linaro.org, aggelerf@ethz.ch, qemu-devel@nongnu.org, agraf@suse.de, blauwirbel@gmail.com, john.williams@xilinx.com, greg.bellows@linaro.org, pbonzini@redhat.com, christoffer.dall@linaro.org, rth@twiddle.net Edgar E. Iglesias writes: > On Tue, Jun 03, 2014 at 11:22:51AM +0100, Alex Bennée wrote: >> >> Edgar E. Iglesias writes: >> >> >> Ahh my confusion from earlier is now clear. Perhaps the two commits >> should be merged? > > Hi, > > The point is to have a non-functional diff and then incrementally add > the function to easy bisectability if something breaks. I don't > have a very strong opinion though, so if people insist I can squash. Having each commit point be buildable and testable is certainly a worthwhile goal from a bisect point of view. But for a simple no-op diff (i.e. functionaly identical, just moving a few bits around) which will then get updated with functional changes there is an argument to squash the two together. I like this patch series because the individual patches are narrow in scope and not too big hence easier to review. I don't think squashing some of non-function + functional diffs together detracts from that nobel goal. As you say it's a judgement call. -- Alex Bennée