On Tue, Oct 04, 2022 at 01:28:27PM +0100, Jon Turney wrote: > 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.
Would it be possible to add some output to the hooks to provide a useful explanation for what's going on? I think anything a hook prints to stdout or stderr will be seen by the user in the `git push` output, and something a bit more informative than "DENIED" would be nice! It's not a big issue either way, but having a more informative output in this case might have saved me a bit of time trying to ensure the problem was genuinely on the server and not just that I was doing something daft. > 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. It's intended; the aim is that folk looking for repositories with packaging code can find them in the common location that's linked from the Cygwin website, but without giving the impression that those are the primary repositories. I'm just using them as a mirror for the actually released code, with the primary repository living on GitHub.
