Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1580540
| From | Paolo Bonzini <pbonzini@redhat.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: linux-next: manual merge of the kvm tree with the powerpc tree |
| Date | 2017-02-14 14:40 +0100 |
| Message-ID | <taLuO-2sF-21@gated-at.bofh.it> (permalink) |
| References | <t9aGZ-6Ul-7@gated-at.bofh.it> <t9gjo-23D-13@gated-at.bofh.it> <taGYb-7UK-31@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 14/02/2017 09:45, Michael Ellerman wrote:
>> If possible, please pull only up to "powerpc/64: Allow for relocation-on
>> interrupts from guest to host" and cherry-pick the top two patches
>> ("powerpc/64: CONFIG_RELOCATABLE support for hmi interrupts" and
>> "powerpc/powernv: Remove separate entry for OPAL real mode calls") into
>> your next branch, but leave the rest for my tree only.
>
> I don't see how that helps anything.
>
> In fact it guarantees a mess because those two commits would now go to
> Linus via my tree (cherry picked) and via Paul's as part of his second
> merge of the topic branch.
>
> So unless you can give me a good reason I'll merge the tip of the topic
> branch into my next, as planned.
Yes, Paul's second merge did guarantee a mess, so go ahead.
However, the reason was that this is simply not how topic branches
should work: topic branches should be the base for other work, they
shouldn't contain _all_ the work. So the right workflow would have been:
- Paul submits topic branch A to you
- you merge A
- Paul merges topic branch A into his "next" branch
- Paul applies KVM-specific patches B1 on top of his "next" branch.
- Paul sends pull request to me (with A + kvmppc work).
As far as I understand, there was no reason for you to get B1.
The last two patches (let's call them B2) also didn't need to go through
the kvm-ppc branch at all. You could have applied them directly on top
of A. Linus then would get A and B2 from you, and A and B1 from me:
base -→ A -----→ B1
↓ ↓
ppc -→ ▪ ▪ ←- kvm
↓ |
B2 |
↓ ↓
torvalds/linux.git
If necessary, things could have been arranged so that Linus got A and B2
from you, and all three of A/B1/B2 from me:
- Paul submits topic branch B2 to you, based on topic branch A
- you merge B2
- Paul merges B2 and I get it from him
The result would have been:
base -→ A -----→ B1
↓ ↘ ↓
ppc -→ ▪ B2 → ▪
↓ ↙ ↓
▪ ▪ ←- kvm
↓ ↓
torvalds/linux.git
Paolo
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: linux-next: manual merge of the kvm tree with the powerpc tree Michael Ellerman <mpe@ellerman.id.au> - 2017-02-14 09:50 +0100
Re: linux-next: manual merge of the kvm tree with the powerpc tree Paolo Bonzini <pbonzini@redhat.com> - 2017-02-14 14:40 +0100
Re: linux-next: manual merge of the kvm tree with the powerpc tree Michael Ellerman <mpe@ellerman.id.au> - 2017-02-15 12:20 +0100
Re: linux-next: manual merge of the kvm tree with the powerpc tree Paolo Bonzini <pbonzini@redhat.com> - 2017-02-15 12:30 +0100
csiph-web