! [remote rejected] master -> master (pre-receive hook declined)

[davidhq]

• Gitea version (or commit ref):

gitea-1.3-linux-amd64

binary on Debian GNU/Linux 9 (stretch)

• Git version:
  2.11.0

• Operating system:

• Database (use [x]):

  • PostgreSQL
  • MySQL
  • MSSQL
  • SQLite

• Can you reproduce the bug at https://try.gitea.io:

  • Yes (provide example URL)
  • No
  • Not relevant

• Log gist:

Description

• I download binary, this version:

~/Install/gitea$ ./gitea-1.3-linux-amd64 --version
Gitea version 4683e54 built with: bindata, sqlite

I ran it with

$ ./gitea-1.3-linux-amd64 web -p 3500
2017/11/21 01:57:20 [T] AppPath: /home/eclipse/Install/gitea/gitea-1.3-linux-amd64
2017/11/21 01:57:20 [T] AppWorkPath: /home/eclipse/Install/gitea
2017/11/21 01:57:20 [T] Custom path: /home/eclipse/Install/gitea/custom
2017/11/21 01:57:20 [T] Log path: /home/eclipse/Install/gitea/log
2017/11/21 01:57:20 Serving [::]:3500 with pid 22540

Then made server reverse proxy on port 80, binding to git.local domain (can be used from macOS)

I then tried to create a new repository on web instance on local network, then trying to push to it according to instructions:

Creating a new repository on the command line
touch README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin http://git.local/davidhq/test.git
git push -u origin master

I tried multiple combinations and variations of everything, always the same message:

$ git push -u origin master
Counting objects: 3, done.
Writing objects: 100% (3/3), 216 bytes | 216.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To http://git.local/davidhq/test.git
 ! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to 'http://git.local/davidhq/test.git'

This was the last try: doing it via .local domain, so that really nothing (Cloudflare etc.) is interfering with trying to push to the repo.

Do you have any tips how to solve the problem?

Another question: when I tried to compile gitea, the version is always reported as Gitea version 1.1.0+774-gfd09d1ff, I think it's baked into Makefile because here also for sure I'm compiling the latest commit from master.

Screenshots

[lunny]

@davidhq I have followed your steps except a reverse proxy. But I cannot reproduce the issue.

➜  testgitea ./gitea-1.3-darwin-10.6-amd64 --version
Gitea version 4683e54 built with: bindata, sqlite

[davidhq]

Hi!

I just tried everything locally on my macOS machine, this time it worked, the difference was that I used postgres and not sqlite3.. Not sure if something else too, I will test more and report.

But for now if you can, just let me know why the version in footer is listed as:

Gitea Version: 1.1.0+779-gea78a6db

I ran make in this directory:

david@eclipse:~/go/src/code.gitea.io/gitea (master)$ git log -1
commit ea78a6db5710c630fc3bd2d1d6c9551ea82b39f9 (HEAD -> master, origin/master, origin/HEAD)
Author: Ethan Koenig <ethantkoenig@gmail.com>
Date:   Mon Nov 20 21:43:00 2017 -0800

    Spaces to tabs in templates (#2953)

Shouldn't the version say something more in the direction: 1.3.0+779-ea78a6db

if not, can you let me know what 1.1.0+779-gea78a6db means? thank you

[lunny]

@davidhq that should be a make file bug.

[kolaente]

I have the same issue with the 1.3 dockerimage, but it does work fine with 1.3.0-rc1

[meoso]

I recently jumped form gitea-1.0.1-linux-amd64 to gitea-master-linux-amd64 (1.3.0 and 1.3.1) and now have this same problem. reverting to 1.0.1 did not fix.

[lunny]

@meoso have you renamed the binary name? if not, please rewrite the public key on admin panel.

[lunny]

@davidhq found it. This is because you used -p but LOCAL_URL doesn't change that port.

[meoso]

this is what i did:

curl -L -o ~/bin/gitea https://dl.gitea.io/gitea/master/gitea-master-linux-amd64
chmod +x ~/bin/gitea
~/bin/gitea web -p 8080

Admin Panel stats shows 0 public keys, and i clicked "Run" for Rewrite '.ssh/authorized_keys' file

...Now i see your new comments, i suppose i need to wait for the fixed binary?

[lunny]

You can run without -p parameter but write the port on custom/conf/app.ini. That should work fine.