From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Merging kvm-apic into qemu-kvm Date: Fri, 27 Jan 2012 22:34:44 +0100 Message-ID: <4F231874.1080503@web.de> References: <4F216E19.3040905@redhat.com> <4F217056.1030609@siemens.com> <4F21720A.9040306@siemens.com> <4F2173B7.2040904@redhat.com> <4F217537.8030202@siemens.com> <4F217612.4020707@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2B390B83BF8DBC27ECDD184B" Cc: KVM list , qemu-devel To: Avi Kivity Return-path: Received: from fmmailgate02.web.de ([217.72.192.227]:48164 "EHLO fmmailgate02.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752840Ab2A0Ver (ORCPT ); Fri, 27 Jan 2012 16:34:47 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id 6B6F71C0799CE for ; Fri, 27 Jan 2012 22:34:46 +0100 (CET) In-Reply-To: <4F217612.4020707@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2B390B83BF8DBC27ECDD184B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-01-26 16:49, Avi Kivity wrote: > On 01/26/2012 05:45 PM, Jan Kiszka wrote: >>> >>>> I merged the upstream patches one by one, resolving the mechanical a= nd >>>> 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.=20 >=20 > 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. >=20 >> Will then >> publish the branch for pulling. Can I start at the current 'next' head= ? >=20 > 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). Done, see git://git.kiszka.org/qemu-kvm.git queues/qemu-merge Only moderately tested so far, I'm counting on your machinery. Jan --------------enig2B390B83BF8DBC27ECDD184B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8jGHQACgkQitSsb3rl5xTZggCfXZQ/uVK9KUGQoyfOXNdauHcJ 8SwAmwURD19mjakRyQV+CwPBOCMs2tG2 =6n58 -----END PGP SIGNATURE----- --------------enig2B390B83BF8DBC27ECDD184B--