From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id 8OF8H9scF2DlYgAA0tVLHw (envelope-from ) for ; Sun, 31 Jan 2021 21:10:51 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id MAVBG9scF2CpfAAAB5/wlQ (envelope-from ) for ; Sun, 31 Jan 2021 21:10:51 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 42FF19404C7 for ; Sun, 31 Jan 2021 21:10:51 +0000 (UTC) Received: from localhost ([::1]:36508 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l6Jze-00047a-8g for larch@yhetil.org; Sun, 31 Jan 2021 16:10:50 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44042) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6JzI-00046k-AE for guix-devel@gnu.org; Sun, 31 Jan 2021 16:10:28 -0500 Received: from world.peace.net ([64.112.178.59]:47978) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l6JzE-0001yJ-4l for guix-devel@gnu.org; Sun, 31 Jan 2021 16:10:28 -0500 Received: from mhw by world.peace.net with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l6JzB-0003lB-B9; Sun, 31 Jan 2021 16:10:21 -0500 From: Mark H Weaver To: Jakub =?utf-8?B?S8SFZHppb8WCa2E=?= , Leo Famulari Subject: Re: branch staging updated (5aeee07 -> 104151f) In-Reply-To: References: Date: Sun, 31 Jan 2021 16:09:01 -0500 Message-ID: <875z3cu83b.fsf@netris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=64.112.178.59; envelope-from=mhw@netris.org; helo=world.peace.net X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: guix-devel@gnu.org, mail@nicolasgoaziou.fr Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: -2.36 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: 42FF19404C7 X-Spam-Score: -2.36 X-Migadu-Scanner: scn1.migadu.com X-TUID: uvJEr8nj7OaW Hi, Jakub K=C4=85dzio=C5=82ka writes: > On Sun Jan 31, 2021 at 6:18 AM CET, Leo Famulari wrote: >> On Sat, Jan 30, 2021 at 06:37:11PM -0500, Mark H Weaver wrote: >> > What would the Git hook do, precisely? The reason I ask is that some >> > bug fixes are appropriate on a frozen branch. How would a Git hook >> > determine whether a given commit should be allowed? >> >> I haven't given much thought to how it would work but, if it ran on the >> client side as a pre-push hook, it could be easily disabled by the >> committer, when necessary. Ah, I see now that 'git push' has the "--no-verify" option, which causes it to skip the pre-push hook. Sure, that sounds workable. > Alternatively, one could include some control sequence in the commit > message. For example, > > Allow-Frozen: staging It's an interesting idea, but it occurs to me that such annotations would have no long-term relevance, and so I'd prefer not to pollute our commit log history with them. A year from now, it's unlikely to be relevant whether a bug fix pushed today happened to be committed to the 'staging' branch when it was frozen. For our purposes, we only need a transient way to disable the pre-push hook, whereas anything included in the commit log is permanent and forever immutable. Therefore, my preference would be to use the "--no-verify" option. I could live with either approach, though. What do you think? Regards, Mark