All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: KVM list <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: Merging kvm-apic into qemu-kvm
Date: Fri, 27 Jan 2012 22:34:44 +0100	[thread overview]
Message-ID: <4F231874.1080503@web.de> (raw)
In-Reply-To: <4F217612.4020707@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

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 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).

Done, see

git://git.kiszka.org/qemu-kvm.git queues/qemu-merge

Only moderately tested so far, I'm counting on your machinery.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@web.de>
To: Avi Kivity <avi@redhat.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, KVM list <kvm@vger.kernel.org>
Subject: Re: [Qemu-devel] Merging kvm-apic into qemu-kvm
Date: Fri, 27 Jan 2012 22:34:44 +0100	[thread overview]
Message-ID: <4F231874.1080503@web.de> (raw)
In-Reply-To: <4F217612.4020707@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

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 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).

Done, see

git://git.kiszka.org/qemu-kvm.git queues/qemu-merge

Only moderately tested so far, I'm counting on your machinery.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2012-01-27 21:34 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-26 15:15 Merging kvm-apic into qemu-kvm Avi Kivity
2012-01-26 15:15 ` [Qemu-devel] " Avi Kivity
2012-01-26 15:25 ` Jan Kiszka
2012-01-26 15:25   ` [Qemu-devel] " Jan Kiszka
2012-01-26 15:32   ` Jan Kiszka
2012-01-26 15:32     ` [Qemu-devel] " Jan Kiszka
2012-01-26 15:39     ` Avi Kivity
2012-01-26 15:39       ` [Qemu-devel] " Avi Kivity
2012-01-26 15:45       ` Jan Kiszka
2012-01-26 15:45         ` [Qemu-devel] " Jan Kiszka
2012-01-26 15:49         ` Avi Kivity
2012-01-26 15:49           ` [Qemu-devel] " Avi Kivity
2012-01-27 21:34           ` Jan Kiszka [this message]
2012-01-27 21:34             ` Jan Kiszka
2012-01-29 10:33             ` Avi Kivity
2012-01-29 10:33               ` [Qemu-devel] " Avi Kivity
2012-01-29 11:12               ` Avi Kivity
2012-01-29 11:12                 ` [Qemu-devel] " Avi Kivity
2012-01-29 11:15                 ` Jan Kiszka
2012-01-29 11:15                   ` [Qemu-devel] " Jan Kiszka
2012-01-29 11:18                   ` Avi Kivity
2012-01-29 11:18                     ` [Qemu-devel] " Avi Kivity
2012-01-29 11:20                     ` Jan Kiszka
2012-01-29 11:20                       ` [Qemu-devel] " Jan Kiszka
2012-01-29 11:54                     ` Jan Kiszka
2012-01-29 11:54                       ` [Qemu-devel] " Jan Kiszka
2012-01-29 12:01                       ` Avi Kivity
2012-01-29 12:01                         ` [Qemu-devel] " Avi Kivity
2012-01-29 12:02                         ` Jan Kiszka
2012-01-29 12:02                           ` [Qemu-devel] " Jan Kiszka
2012-01-29 12:04                           ` Avi Kivity
2012-01-29 12:04                             ` [Qemu-devel] " Avi Kivity
2012-01-29 12:06                             ` Avi Kivity
2012-01-29 12:06                               ` [Qemu-devel] " Avi Kivity
2012-01-29 12:35                               ` Avi Kivity
2012-01-29 12:35                                 ` [Qemu-devel] " Avi Kivity
2012-01-29 15:56                                 ` Avi Kivity
2012-01-29 15:56                                   ` [Qemu-devel] " Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F231874.1080503@web.de \
    --to=jan.kiszka@web.de \
    --cc=avi@redhat.com \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.