From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.81]) by mx.groups.io with SMTP id smtpd.web10.1222.1583826815087123751 for ; Tue, 10 Mar 2020 00:53:35 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=hWO6coeM; spf=pass (domain: redhat.com, ip: 207.211.31.81, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1583826814; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ogitByb49JYE0l13UrY715mPPiwJIc8Yo8J7hjA6A2E=; b=hWO6coeMJ3LZmFliaaY+qBWDzqxdPmDAEaa6/idP7DlHNK64n0m/W4LbrhQGcsBgAMfDYD 38vHEw/G9itLAAX3BoC/EbpbY9XurMBcwEm+6EFjGkI3tTPBxiWMe+GB35YD+ef9r9mHEG N/49lEJg/W88o5hWiInwm/U//Efu4RA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-121-Ijuwjjm6P26bbpxYu4_vhw-1; Tue, 10 Mar 2020 03:53:31 -0400 X-MC-Unique: Ijuwjjm6P26bbpxYu4_vhw-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 2872C477; Tue, 10 Mar 2020 07:53:30 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-246.ams2.redhat.com [10.36.116.246]) by smtp.corp.redhat.com (Postfix) with ESMTP id 94538100164D; Tue, 10 Mar 2020 07:53:28 +0000 (UTC) Subject: Re: [edk2-devel] EDK II Maintainers - EDK II CI is now active on edk2/master To: "Kinney, Michael D" , "devel@edk2.groups.io" , "sean.brogan@microsoft.com" , Bret Barkelew , "Gao, Liming" Cc: "Leif Lindholm (Nuvia address)" , Andrew Fish References: From: "Laszlo Ersek" Message-ID: <5364bb7d-2a78-432d-deae-e648e24f4de4@redhat.com> Date: Tue, 10 Mar 2020 08:53:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/09/20 22:44, Kinney, Michael D wrote: > Laszlo, > > If the dev branch that is being submitted as a PR > contains the merge commit, or that developer use the > one of the github features to rebase, the merge > commit can be introduced. > > When a PR is in this state, the developer need to > clean up their history locally and do a forced > push or open a new PR. > > In the case, it looks like PatchCheck did a good > job of rejecting a patch series we would not want > added. I agree that PatchCheck was right to refuse the merge commit, I'm just very confused about the origin of that merge commit. The list of commits noted in Ard's original PR did not include a merge commit. Also, it's very unlikely for Ard to rely on github for a genuine rebase; he'd just do it locally. Anyway, the particular patches have now been merged correctly via . Thanks! Laszlo