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
