From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out-so.shaw.ca (smtp-out-so.shaw.ca [64.59.136.139]) by sourceware.org (Postfix) with ESMTPS id 7C89E385802D for ; Sat, 29 May 2021 16:55:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 7C89E385802D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=SystematicSw.ab.ca Authentication-Results: sourceware.org; spf=none smtp.mailfrom=brian.inglis@systematicsw.ab.ca Received: from [192.168.1.104] ([68.147.0.90]) by shaw.ca with ESMTP id n2FZl0rWU7YjPn2Falx0wH; Sat, 29 May 2021 10:55:50 -0600 X-Authority-Analysis: v=2.4 cv=fPVaYbWe c=1 sm=1 tr=0 ts=60b27216 a=T+ovY1NZ+FAi/xYICV7Bgg==:117 a=T+ovY1NZ+FAi/xYICV7Bgg==:17 a=IkcTkHD0fZMA:10 a=w_pzkKWiAAAA:8 a=VUn_Jsy4jMUumIPVK2oA:9 a=QEXdDO2ut3YA:10 a=sRI3_1zDfAgwuvI8zelB:22 From: Brian Inglis Reply-To: cygwin-apps@cygwin.com To: cygwin-apps@cygwin.com References: <59806a9c-a0f4-1868-e763-4dca35e6e3a2@gmail.com> <1e51a907-b7cb-3961-db13-3f4b74a8ddff@SystematicSw.ab.ca> <1fe9bb8f-327d-c9fc-9b5c-31c7471073d1@gmail.com> Organization: Systematic Software Subject: Re: [ITA] nghttp2, mingw64-{x86_64,i686}-nghttp2 Message-ID: Date: Sat, 29 May 2021 10:55:49 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4xfFfERM4CTEvhEkBeGGr+Da/lIF73niajntWPt+voeYzofDGbjfajHUc9wl04/KXsdiuZ8gGq8tJ4KjScnzfAMTpj8//DRy3SEavdDN40AfnCpxSA2+57 5E1kloDDbC9PLPxRJRrgsAgQP/p+A+19SXmUfxwbLQtNu3vnR6m/gCtafR3gepdploc7Rr/1mbwiqE3PhCJe+JnTz35Cnqw/Ie0= X-Spam-Status: No, score=-3486.2 required=5.0 tests=BAYES_00, BODY_8BITS, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_BARRACUDACENTRAL, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-apps@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin package maintainer discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 May 2021 16:55:53 -0000 On 2021-05-29 04:09, Jon Turney wrote: > On 29/05/2021 07:12, Marco Atzeri via Cygwin-apps wrote: >> On 29.05.2021 06:37, Brian Inglis wrote: >>> until I can get git-cygwin-packages working again - see below! >>>>> Changed maintainership to you (only for them this time) >>>> Thank you very much - appreciate that! >>> Do I also have ownership of: >> should be >> but Jon is the expert here >>> I am getting the following responses whenever I try to push to >>> either playground or master branches!... >>> $ git push >>> Enumerating objects: 11, done. >>> Counting objects: 100% (11/11), done. >>> Delta compression using up to 4 threads >>> Compressing objects: 100% (7/7), done. >>> Writing objects: 100% (9/9), 2.23 KiB | 326.00 KiB/s, done. >>> Total 9 (delta 2), reused 0 (delta 0), pack-reused 0 >>> remote: 'there can be only one!' at /sourceware1/cygwin-staging/gitolite.git/src/VREF/HIGHLANDER line 27. >>> remote: FATAL: VREF/HIGHLANDER/cygport: helper program exit status 65280 >>> remote: error: hook declined to update refs/heads/playground >>> To ssh://cygwin/git/cygwin-packages/nghttp2 >>>   ! [remote rejected]           playground -> playground (hook declined) >>> error: failed to push some refs to 'ssh://cygwin/git/cygwin-packages/nghttp2' > This is a new trigger I turned on recently, which (is supposed to) > prevent pushes of trees which contain more than one .cygport file > (since that complicates navigating from source package name to git > history of the .cygport file in ways I have no interest in > implementing) > I've tuned this down to a warning at the moment (and made it a bit > clearer) so you should be able to proceed. > Can you provide a commit id which triggers this which but shouldn't, > and I'll try to work out why... Criterion for having "only one!"? There's a .cygport on both playground and master branches? Which is kind of the point of having branches! ;^> $ git push Enumerating objects: 14, done. Counting objects: 100% (14/14), done. Delta compression using up to 4 threads Compressing objects: 100% (10/10), done. Writing objects: 100% (12/12), 2.49 KiB | 425.00 KiB/s, done. Total 12 (delta 4), reused 0 (delta 0), pack-reused 0 remote: warning: adae2d9f76a662dbf0151e8a48b750bf93dd2d13 seems to contain more than one .cygport file remote: this is bad and you should feel bad remote: scallywag: build 2916 queued remote: scallywag: https://cygwin.com/cgi-bin2/jobs.cgi?id=2916 To ssh://cygwin/git/cygwin-packages/nghttp2 ee14bc998685..adae2d9f76a6 playground -> playground $ This seems to have committed/pushed one of my mingw64 package subdirectories, which has its own repo and .git tree: https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/nghttp2.git;a=tree;h=refs/heads/playground;hb=refs/heads/playground How do I get rid of that object and keep the real files? Can I copy that dir tree and just git rm and push all the objects? I may have already merged those objects into master as part of earlier tests. Will re-merging playground after rm fix those up? Only thing I can think of is that I somehow managed to get to the state below, perhaps by trying to stage/add/commit files in mingw... subdirectories, which may have been propagated up to the parent directory if lacking its own .git tree, if I had not yet cloned the mingw git/cygwin-packages repos: $ git status -b -v On branch playground Your branch is based on 'origin/playground', but the upstream is gone. (use "git branch --unset-upstream" to fixup) Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) typechange: mingw64-x86_64-nghttp2/configure-ac-cxx-ext.patch modified: mingw64-x86_64-nghttp2/mingw64-x86_64-nghttp2.cygport typechange: mingw64-x86_64-nghttp2/tests-Makefile-am-staticlib.patch Untracked files: (use "git add ..." to include in what will be committed) 1.7.1-win32-tests.patch check.uri ci.uri gdrive.uri nghttp2-1.37.0-1.i686/ nghttp2-1.37.0-1.x86_64/ nghttp2-1.43.0-1.i686/ nghttp2-1.43.0-1.x86_64/ nghttp2-i686-ci.log nghttp2-update-1.43.eml nghttp2-x86_64-ci.log no changes added to commit (use "git add" and/or "git commit -a") $ which I undid with a: $ git stash Saved working directory and index state WIP on playground: 29e92b49619d add empty python module subpackages to obsolete $ although I thought I had previously cloned those earlier: $ llgo -A {*/,}.git/config -rw-r--r-- 1 426 May 28 22:21 .git/config -rw-r--r-- 1 371 May 28 09:00 mingw64-i686-nghttp2/.git/config -rw-r--r-- 1 373 May 28 08:53 mingw64-x86_64-nghttp2/.git/config $ tail -n+0 {*/,}.git/config ==> mingw64-i686-nghttp2/.git/config <== [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote "origin"] url = ssh://cygwin/git/cygwin-packages/mingw64-i686-nghttp2.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "playground"] remote = origin merge = refs/heads/playground ==> mingw64-x86_64-nghttp2/.git/config <== [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote "origin"] url = ssh://cygwin/git/cygwin-packages/mingw64-x86_64-nghttp2.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "playground"] remote = origin merge = refs/heads/playground ==> .git/config <== [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true ignorecase = true [remote "origin"] url = ssh://cygwin/git/cygwin-packages/nghttp2.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = ssh://cygwin/git/cygwin-packages/nghttp2 merge = refs/heads/master [branch "playground"] remote = ssh://cygwin/git/cygwin-packages/nghttp2 merge = refs/heads/playground $ -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.]