From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60662) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqRaB-0001kL-B7 for qemu-devel@nongnu.org; Thu, 26 Jan 2012 10:49:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RqRa4-0005bS-6w for qemu-devel@nongnu.org; Thu, 26 Jan 2012 10:49:51 -0500 Received: from mx1.redhat.com ([209.132.183.28]:6093) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RqRa3-0005Zq-V2 for qemu-devel@nongnu.org; Thu, 26 Jan 2012 10:49:44 -0500 Message-ID: <4F217612.4020707@redhat.com> Date: Thu, 26 Jan 2012 17:49:38 +0200 From: Avi Kivity MIME-Version: 1.0 References: <4F216E19.3040905@redhat.com> <4F217056.1030609@siemens.com> <4F21720A.9040306@siemens.com> <4F2173B7.2040904@redhat.com> <4F217537.8030202@siemens.com> In-Reply-To: <4F217537.8030202@siemens.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Merging kvm-apic into qemu-kvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: qemu-devel , KVM list On 01/26/2012 05:45 PM, Jan Kiszka wrote: > > > >> I merged the upstream patches one by one, resolving the mechanical and > >> logical conflicts in each step. Was done for that backend/frontend > >> concept, but the adjustments should basically be the same now. Want me > >> to prepare a branch or will you do this? > > > > It's much more likely that you'll get it right - I started to do this > > but backed out. > > > > btw, the branch doesn't appear to be merges, so I'll still have huge > > conflicts at the end. If you do this with real merges, git will > > recognize it and just adopt your version. > > I will try to use your concept: pull in upstream commits into a merge > branch as long as there is a mechanical or logical conflict. That's what I do in my upstream merges. I use bisect to find the first conflict, but in this case I imagine there will be a conflict in every merge except the memory.c one. > Will then > publish the branch for pulling. Can I start at the current 'next' head? Yes please. It's halfway through autotest and looks good. Even if I have to change it, we can 'git rebase -p --onto' your branch (though I doubt it will be necessary). -- error compiling committee.c: too many arguments to function