Received-SPF: pass (google.com: domain of linux-kernel+bounces-65688-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240213005710.672448-1-seanjc@google.com>
In-Reply-To: <20240213005710.672448-1-seanjc@google.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Date: Wed, 14 Feb 2024 18:35:12 +0100
Message-ID: <CABgObfbQqVOsH0imHWc938n48TdkD8xFPO4CnwS0EM4oQZAxog@mail.gmail.com>
Subject: Re: [GIT PULL (sort of)] KVM: x86: fixes and selftests fixes/cleanups
To: Sean Christopherson <seanjc@google.com>
Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Feb 13, 2024 at 1:57=E2=80=AFAM Sean Christopherson <seanjc@google.=
com> 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-rc=
1 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 d=
on'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 thr=
ow
> 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