From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27029 invoked by alias); 17 Jan 2020 08:06:30 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 27020 invoked by uid 89); 17 Jan 2020 08:06:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.1 required=5.0 tests=AWL,BAYES_00,KAM_COUK,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1 spammy=transparent, habit, didn, emails X-HELO: smtp2.wavenetuk.net Received: from smtp.wavenetuk.net (HELO smtp2.wavenetuk.net) (195.26.37.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Jan 2020 08:06:19 +0000 Received: from [192.168.1.212] (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp2.wavenetuk.net (Postfix) with ESMTPA id 84F3860015E; Fri, 17 Jan 2020 08:06:17 +0000 (GMT) Content-Type: text/plain; charset=utf-8; delsp=yes; format=flowed Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: limit on emails for merge commits. From: Iain Sandoe In-Reply-To: <20200117075611.GC14671@adacore.com> Date: Fri, 17 Jan 2020 08:29:00 -0000 Cc: Joseph Myers , GCC Patches , "Richard Earnshaw (lists)" Content-Transfer-Encoding: 8bit Message-Id: <56EBA2AB-EA82-4060-855F-6B052600F0A8@sandoe.co.uk> References: <20200117075611.GC14671@adacore.com> To: Joel Brobecker X-SW-Source: 2020-01/txt/msg01017.txt.bz2 Hi Folks, Joel Brobecker wrote: >> You should include Joel on such questions as the expert on the hooks. >> >> I don't know whether there's something to put in the commit message to say >> "allow this merge of more than 100 commits". I don't think a squashed >> merge is the right workaround, supposing you do want the git ancestry >> information to reflect what got merged. The simple workaround is to do >> three successive merges, each of under 100 commits and each pushed >> separately. Alternatively, you could check out refs/meta/config, push a >> change that either increases hooks.max-commit-emails or sets >> hooks.no-emails to prevent mails for this branch, then push the merge, >> then push a reversion of the change to refs/meta/config. > > Joseph pretty much nailed it in terms of options. Yeah - I agree. I didn’t do the squash merge because I don’t want to lose the ancestor history on the branch. For the sake of separating the process of merging coroutines from our general git policies, I am going to use several smaller merges - this is a simple and transparent workaround. I think editing the hooks would be less transparent and doesn’t solve the ‘spamming the commits ML’ any better. --- As I noted, 100 commits to master is a small number, so I expect this problem to fire almost every time someone does a merge of master to a devel or user branch (unless they have the habit of doing that almost daily, which I doubt for most). thanks Iain