I have two pull requests for 6.8, but I goofed (or maybe raced with you
pushing to kvm/master), and based everything on 6.8-rc2 instead of 6.8-rc1 as
you did. And so of course the pull requests would bring in waaaaay more than
just the intended KVM changes.
Can I bribe you to do a back merge of 6.8-rc2, so that my pull requests don't
make me look like a complete idiot?
It's not the end of the world for me to rebase, but I'd prefer not to throw
away the hashes and the time the commits have spent in -next.
FWIW, the two tags are:
https://github.com/kvm-x86/linux.git tags/kvm-x86-fixes-6.8-rcN
https://github.com/kvm-x86/linux.git tags/kvm-x86-selftests-6.8-rcN
On Tue, Feb 13, 2024 at 1:57 AM Sean Christopherson <[email protected]> wrote:
>
> I have two pull requests for 6.8, but I goofed (or maybe raced with you
> pushing to kvm/master), and based everything on 6.8-rc2 instead of 6.8-rc1 as
> you did. And so of course the pull requests would bring in waaaaay more than
> just the intended KVM changes.
>
> Can I bribe you to do a back merge of 6.8-rc2, so that my pull requests don't
> make me look like a complete idiot?
Ignoring the fact that kvm/master is currently a subset of Linus's
tree (so I can just fast forward to -rc4 before merging your stuff),
that's absolutely not a problem and it happens all the time during the
merge window. The way to handle that is to forge the diffstat in the
pull request, replacing it with the diffstat of the test merge commit
that I do anyway. It's a known issue with git-request-pull and pretty
much all maintainers do it.
But for -rc pull requests what I do is just base the PR on the latest
-rc, and in fact I've started doing something similar recently since I
have very few commits of my own in kvm/next. I always start with a
very late -rc and merge in all the topic branches one by one. Instead
of starting from kvm/next, I checkout -rc6 or so, then merge in the
contents of kvm/next with a "Merge branch 'kvm-6.9-paolo" commit
message (important: git sees this as a fast forward!!), and then apply
submaintainer trees on top. This results in no back merges, and it's
only cheating a little bit.
> It's not the end of the world for me to rebase, but I'd prefer not to throw
> away the hashes and the time the commits have spent in -next.
>
> FWIW, the two tags are:
>
> https://github.com/kvm-x86/linux.git tags/kvm-x86-fixes-6.8-rcN
> https://github.com/kvm-x86/linux.git tags/kvm-x86-selftests-6.8-rcN
Pulled (but not pushed), thanks.
Paolo
On Wed, Feb 14, 2024, Paolo Bonzini wrote:
> On Tue, Feb 13, 2024 at 1:57 AM Sean Christopherson <[email protected]> wrote:
> >
> > I have two pull requests for 6.8, but I goofed (or maybe raced with you
> > pushing to kvm/master), and based everything on 6.8-rc2 instead of 6.8-rc1 as
> > you did. And so of course the pull requests would bring in waaaaay more than
> > just the intended KVM changes.
> >
> > Can I bribe you to do a back merge of 6.8-rc2, so that my pull requests don't
> > make me look like a complete idiot?
>
> Ignoring the fact that kvm/master is currently a subset of Linus's
> tree (so I can just fast forward to -rc4 before merging your stuff),
> that's absolutely not a problem and it happens all the time during the
> merge window. The way to handle that is to forge the diffstat in the
> pull request, replacing it with the diffstat of the test merge commit
> that I do anyway. It's a known issue with git-request-pull and pretty
> much all maintainers do it.
Heh, I did that locally, but sending out a forged diffstat felt dirty. Though I
guess it all works out, so long as I make it clear that the base isn't kvm/master.
Thanks!