From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Merging kvm-apic into qemu-kvm Date: Thu, 26 Jan 2012 17:49:38 +0200 Message-ID: <4F217612.4020707@redhat.com> References: <4F216E19.3040905@redhat.com> <4F217056.1030609@siemens.com> <4F21720A.9040306@siemens.com> <4F2173B7.2040904@redhat.com> <4F217537.8030202@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: KVM list , qemu-devel To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:62381 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752674Ab2AZPtq (ORCPT ); Thu, 26 Jan 2012 10:49:46 -0500 In-Reply-To: <4F217537.8030202@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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