From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from re-prd-fep-044.btinternet.com (mailomta18-re.btinternet.com [213.120.69.111]) by sourceware.org (Postfix) with ESMTPS id 480C6385801A for ; Tue, 4 Oct 2022 12:28:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 480C6385801A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=dronecode.org.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=dronecode.org.uk Received: from re-prd-rgout-001.btmx-prd.synchronoss.net ([10.2.54.4]) by re-prd-fep-044.btinternet.com with ESMTP id <20221004122828.MUGV3224.re-prd-fep-044.btinternet.com@re-prd-rgout-001.btmx-prd.synchronoss.net>; Tue, 4 Oct 2022 13:28:28 +0100 Authentication-Results: btinternet.com; auth=pass (PLAIN) smtp.auth=jonturney@btinternet.com; bimi=skipped X-SNCR-Rigid: 613A8CC33C949B84 X-Originating-IP: [81.153.98.187] X-OWM-Source-IP: 81.153.98.187 (GB) X-OWM-Env-Sender: jonturney@btinternet.com X-VadeSecure-score: verdict=clean score=0/300, class=clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeiuddgheefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuueftkffvkffujffvgffngfevqffopdfqfgfvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpeflohhnucfvuhhrnhgvhicuoehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkqeenucggtffrrghtthgvrhhnpeffkeeigfdujeehteduiefgjeeltdelgeelteekudetfedtffefhfeufefgueettdenucfkphepkedurdduheefrdelkedrudekjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopegludelvddrudeikedruddruddtiegnpdhinhgvthepkedurdduheefrdelkedrudekjedpmhgrihhlfhhrohhmpehjohhnrdhtuhhrnhgvhiesughrohhnvggtohguvgdrohhrghdruhhkpdhnsggprhgtphhtthhopedvpdhrtghpthhtoheprggurghmseguihhnfihoohguihgvrdhorhhgpdhrtghpthhtoheptgihghifihhnqdgrphhpshestgihghifihhnrdgtohhm X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean Received: from [192.168.1.106] (81.153.98.187) by re-prd-rgout-001.btmx-prd.synchronoss.net (5.8.716.04) (authenticated as jonturney@btinternet.com) id 613A8CC33C949B84; Tue, 4 Oct 2022 13:28:28 +0100 Message-ID: Date: Tue, 4 Oct 2022 13:28:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: Cygwin Git repos refusing push Content-Language: en-GB To: Adam Dinwoodie , "cygwin-apps@cygwin.com" References: <20221004075508.akit65zoarxid6r2@lucy.dinwoodie.org> From: Jon Turney In-Reply-To: <20221004075508.akit65zoarxid6r2@lucy.dinwoodie.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3570.0 required=5.0 tests=BAYES_00,FORGED_SPF_HELO,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,RCVD_IN_BARRACUDACENTRAL,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 04/10/2022 08:55, Adam Dinwoodie wrote: > There's a hook on the Cygwin Git infrastructure that is refusing to > accept updated tags for the git package. There's no explanation of why > the push is being rejected, but this worked four weeks ago when I pushed > v2.37.3-1, and is failing now. [...] > > $ git push cygwin v2.38.0-1 > Enumerating objects: 10, done. > Counting objects: 100% (10/10), done. > Delta compression using up to 4 threads > Compressing objects: 100% (8/8), done. > Writing objects: 100% (8/8), 762 bytes | 381.00 KiB/s, done. > Total 8 (delta 6), reused 0 (delta 0), pack-reused 0 > remote: FATAL: W refs/tags/v2.38.0-1 git/cygwin-packages/git Adam_Dinwoodie DENIED by fallthru > remote: error: hook declined to update refs/tags/v2.38.0-1 > To cygwin.com:git/cygwin-packages/git.git > ! [remote rejected] v2.38.0-1 -> v2.38.0-1 (hook declined) > error: failed to push some refs to 'cygwin.com:git/cygwin-packages/git.git' > > Is this a bug in the server side hooks, or have I missed some expected > change in behaviour here? It's not a big deal -- I'm not using the Thanks for reporting this. A few weeks ago, I made a change to prevent pushes to branches which don't have a defined role in our scheme (i.e anything not 'master' or 'playground'), and accidentally prevented tags from being pushed as well. I've adjusted the gitolite configuration so this should work again. In passing, I notice that this repo doesn't have a master branch, only tags, as that has never been pushed to, which may or may not be what you intended.