On Thu, Apr 06, 2023, Xinghui Li wrote: > On Wed, Apr 5, 2023 at 7:44 AM Sean Christopherson <seanjc@xxxxxxxxxx> wrote: > > > > On Mon, 03 Apr 2023 17:52:00 +0800, korantwork@xxxxxxxxx wrote: > > > VMCB_AVIC_APIC_BAR_MASK is defined twice with the same value in svm.h, > > > which is meaningless. Delete the duplicate one. > > > > Applied to kvm-x86 svm, thanks! > > > > In the future, please don't use "PATCH REBASED". If you're sending a new > > version of a patch that's been rebased, then the revision number needs to be > > bumped. The fact that the only change is that the patch was rebased isn't > > relevant as far as versioning is concerned, it's still a new version. The > > cover letter and/or ignored part of the patch is where the delta between > > versions should be captured. > > > > And in this case, there really was no need to send a new version, the original > > patch still applies cleanly. I suspect that the REBASED version was sent as a > > form of a ping, which again is not the right way to ping a patch/series. If you > > want to ping, please reply to the original patch. Unnecessarily sending new > > versions means more patches to sort through, i.e. makes maintainers lives harder, > > not easier. > > > Firstly, I'm so so SORRY to burden you in this way. > I found the last patch can't be am directly, so I send a new patch > with the last rebased code. Ah, try `git am -3`, i.e. tell git to try a 3-way merge between the patch, its base, and what you're applying on. I'm sure there are situations where a 3-way merge is unwanted, e.g. maybe if someone needs to be super paranoid? But for me personally at least, I pretty much always run am with -3. > I used to believe that this would alleviate your burden, but > unfortunately, it had the opposite effect. > Again, sorry for my wrong operation. No worries, it's not a big deal. My lengthy response was purely to help avoid similar mistakes in the future. Thanks!
