Respository&#39;s home page not updated after first push #1502

@vfricou commented on GitHub (Feb 5, 2018):

+1 here. Same things with self deployed 1.4.0-rc1. (Updated from 1.3.2)

@vfricou commented on GitHub (Feb 5, 2018): +1 here. Same things with self deployed 1.4.0-rc1. (Updated from 1.3.2)

GiteaMirror commented

@lafriks commented on GitHub (Feb 5, 2018):

Can you reproduce that on https://try.gitea.io/? I can not seem to be able to reproduce that

@lafriks commented on GitHub (Feb 5, 2018): Can you reproduce that on https://try.gitea.io/? I can not seem to be able to reproduce that

GiteaMirror commented

@arount commented on GitHub (Feb 6, 2018):

@lafriks No, I cannot

@arount commented on GitHub (Feb 6, 2018): @lafriks No, I cannot

GiteaMirror commented

@aligator commented on GitHub (Feb 9, 2018):

I have the same issue but only if I push with https. Pushing with ssh works.

Here is a related issue:
https://github.com/go-gitea/gitea/issues/2898

@aligator commented on GitHub (Feb 9, 2018): I have the same issue but only if I push with https. Pushing with ssh works. Here is a related issue: https://github.com/go-gitea/gitea/issues/2898

GiteaMirror commented

https://gist.github.com/lordlethis/87ed693593f750077b0096931053288f

@lordlethis commented on GitHub (Feb 13, 2018):

I'm having the same issue on raspbian (git 2.1.4, mysql 5.5.59). The syslog shows an error when POSTing to /api/internal/push/update (line 9 in the gist)

@lordlethis commented on GitHub (Feb 13, 2018): I'm having the same issue on raspbian (git 2.1.4, mysql 5.5.59). The syslog shows an error when POSTing to `/api/internal/push/update` (line 9 in the gist) https://gist.github.com/lordlethis/87ed693593f750077b0096931053288f

GiteaMirror commented

@lafriks commented on GitHub (Feb 13, 2018):

@lordlethis Can you please check gitea.log file and give me error at that time in this log file as I can not reproduce it myself

@lafriks commented on GitHub (Feb 13, 2018): @lordlethis Can you please check gitea.log file and give me error at that time in this log file as I can not reproduce it myself

GiteaMirror commented

@lordlethis commented on GitHub (Feb 13, 2018):

I don't see anything resembling an error in gitea.log, I'm afraid.

I changed the config to RUN_MODE=dev and log.LEVEL=Trace and updated the previous gist with the new, more verbose output in the syslog, as well as what's in gitea.log.

Should I change anything further for more useful logs?

@lordlethis commented on GitHub (Feb 13, 2018): I don't see anything resembling an error in gitea.log, I'm afraid. I changed the config to RUN_MODE=dev and log.LEVEL=Trace and updated the previous gist with the new, more verbose output in the syslog, as well as what's in gitea.log. Should I change anything further for more useful logs?

GiteaMirror commented

@Yrek commented on GitHub (Feb 21, 2018):

I have same problem with 1.4.0+rc1.
Running Gitea with Git 2.16 and PostgreSQL 10 on CentOS 7.
For me the problem occurs om both HTTP and SSH.
When checking the xorm.log and hook-logs i can't see any errors.

@Yrek commented on GitHub (Feb 21, 2018): I have same problem with 1.4.0+rc1. Running Gitea with Git 2.16 and PostgreSQL 10 on CentOS 7. For me the problem occurs om both HTTP and SSH. When checking the xorm.log and hook-logs i can't see any errors.

GiteaMirror commented

2025-11-02 04:02:48 -06:00

@lunny commented on GitHub (Feb 22, 2018):

Maybe you can try this add "LOCAL_ROOT_URL=http://127.0.0.1:3000" in custom/app.ini under "server".

@lunny commented on GitHub (Feb 22, 2018): Maybe you can try this `add "LOCAL_ROOT_URL=http://127.0.0.1:3000" in custom/app.ini under "server"`.

GiteaMirror commented

@lordlethis commented on GitHub (Feb 26, 2018):

LOCAL_ROOT_URL=http://127.0.0.1:3000/ makes no difference, I'm afraid. (It made one without the trailing slash, but just in the form of a new error). The only difference I can find is that some logged URLs switch from localhost to 127.0.0.1:

[T] GetProtectedBranchBy: http://127.0.0.1:3000/api/internal/branch/{num}/master (pre-receive.log) and
[T] PushUpdate: http://127.0.0.1:3000/api/internal/push/update (post-receive.log)

@lordlethis commented on GitHub (Feb 26, 2018): `LOCAL_ROOT_URL=http://127.0.0.1:3000/` makes no difference, I'm afraid. (It made one without the trailing slash, but just in the form of a new error). The only difference I can find is that some logged URLs switch from localhost to 127.0.0.1: `[T] GetProtectedBranchBy: http://127.0.0.1:3000/api/internal/branch/{num}/master` (pre-receive.log) and `[T] PushUpdate: http://127.0.0.1:3000/api/internal/push/update` (post-receive.log)

GiteaMirror commented

2025-11-02 04:02:48 -06:00

@lordlethis commented on GitHub (Feb 26, 2018):

I went and tried to reproduce the issue by making a fresh install in a VM.

Setup

Install debian jessie. I used the i386 netinst iso. At the end of the installation, it offers some package groups. I used:
- no desktop
- yes to web server
- no print server
- yes to openssh
- yes to standard utilities

run some commands:

# apt-get install vim git mysql-server
# useradd -d /var/lib/gitea -c "gitea user" -U -r -s /bin/bash gitea
# mkdir /var/lib/gitea && chown gitea: /var/lib/gitea
# mysql -h localhost -u root
mysql> create database gitea;
mysql> grant all on gitea.* to 'gitea'@'localhost' identified by 'gitea';
# wget -O /usr/local/bin/gitea https://dl.gitea.io/gitea/1.4/gitea-1.4-linux-386 && chmod +x /usr/local/bin/gitea

put the following into /etc/systemd/system/gitea.service

[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
After=mysqld.service

[Service]
RestartSec=2s
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/var/lib/gitea
ExecStart=/usr/local/bin/gitea web
Restart=always
Environment=USER=gitea HOME=/var/lib/gitea GITEA_CUSTOM=/var/lib/gitea/custom GITEA_WORK_DIR=/var/lib/gitea/work

[Install]
WantedBy=multi-user.target

run gitea
# systemctl start gitea

Gitea Setup Page

Database

fill in db data (mysql, the db+user we set up earlier)
set application url

Optional

disable OpenID sign-in
disable self-registration

Admin account

fill in an admin user+password+email (why is the email mandatory??)

Issue Reproduction

using the admin account, create a new user
login as the new user, create a new repository
push to that new repository (I'm using http)
look at the repo in gitea, see it still shows the Quick Guide (note that cloning the repo works perfectly fine at that point, and will fetch whatever was pushed earlier)
make another change, push it, and the repository page will show the repo browser and readme display
repeat steps from 'create new repository' on as needed :-)

@lordlethis commented on GitHub (Feb 26, 2018): I went and tried to reproduce the issue by making a fresh install in a VM. # Setup - Install debian jessie. I used the i386 netinst iso. At the end of the installation, it offers some package groups. I used: - no desktop - yes to web server - no print server - yes to openssh - yes to standard utilities - run some commands: ````` # apt-get install vim git mysql-server # useradd -d /var/lib/gitea -c "gitea user" -U -r -s /bin/bash gitea # mkdir /var/lib/gitea && chown gitea: /var/lib/gitea # mysql -h localhost -u root mysql> create database gitea; mysql> grant all on gitea.* to 'gitea'@'localhost' identified by 'gitea'; # wget -O /usr/local/bin/gitea https://dl.gitea.io/gitea/1.4/gitea-1.4-linux-386 && chmod +x /usr/local/bin/gitea ````` - put the following into /etc/systemd/system/gitea.service ````` [Unit] Description=Gitea (Git with a cup of tea) After=syslog.target After=network.target After=mysqld.service [Service] RestartSec=2s Type=simple User=gitea Group=gitea WorkingDirectory=/var/lib/gitea ExecStart=/usr/local/bin/gitea web Restart=always Environment=USER=gitea HOME=/var/lib/gitea GITEA_CUSTOM=/var/lib/gitea/custom GITEA_WORK_DIR=/var/lib/gitea/work [Install] WantedBy=multi-user.target ````` - run gitea `# systemctl start gitea` ## Gitea Setup Page ### Database - fill in db data (mysql, the db+user we set up earlier) - set application url ### Optional - disable OpenID sign-in - disable self-registration ### Admin account - fill in an admin user+password+email (why is the email mandatory??) # Issue Reproduction - using the admin account, create a new user - login as the new user, create a new repository - push to that new repository (I'm using http) - look at the repo in gitea, see it still shows the Quick Guide (note that cloning the repo works perfectly fine at that point, and will fetch whatever was pushed earlier) - make another change, push it, and the repository page will show the repo browser and readme display - repeat steps from 'create new repository' on as needed :-)

GiteaMirror commented

2025-11-02 04:02:48 -06:00

@lafriks commented on GitHub (Mar 21, 2018):

Can you please verify that directory where gitea repsitories are stored does not have noexec flag for filesystem?
Please provide output of cat /proc/mounts

@lafriks commented on GitHub (Mar 21, 2018): Can you please verify that directory where gitea repsitories are stored does not have `noexec` flag for filesystem? Please provide output of `cat /proc/mounts`

GiteaMirror commented

@NyxCode commented on GitHub (Mar 21, 2018):

Can you please verify that directory where gitea repsitories are stored does not have noexec flag for filesystem?
Please provide output of cat /proc/mounts

That fixed it for me!

@NyxCode commented on GitHub (Mar 21, 2018): > Can you please verify that directory where gitea repsitories are stored does not have noexec flag for filesystem? Please provide output of cat /proc/mounts That fixed it for me!

GiteaMirror commented

@mxmehl commented on GitHub (Mar 23, 2018):

So can we close here to finish the 1.4.0 milestone? ;)

@mxmehl commented on GitHub (Mar 23, 2018): So can we close here to finish the 1.4.0 milestone? ;)

GiteaMirror commented

@lordlethis commented on GitHub (Mar 23, 2018):

Doesn't appear to do anything for me. :(

$ cat /proc/mounts
/dev/root / ext4 rw,noatime,data=ordered 0 0
devtmpfs /dev devtmpfs rw,relatime,size=468148k,nr_inodes=117037,mode=755 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
tmpfs /etc/machine-id tmpfs ro,mode=755 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/mmcblk0p1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0

Gitea is based in /var/lib/gitea, repos are in /var/lib/gitea/gitea-repositories/{user}, which is both on the root filesystem.

(Random thought: if the repositories were on a noexec filesystem shouldn't the repo home page never update? Because as it is, it updates with the second push, just not with the first one)

@lordlethis commented on GitHub (Mar 23, 2018): Doesn't appear to do anything for me. :( ````` $ cat /proc/mounts /dev/root / ext4 rw,noatime,data=ordered 0 0 devtmpfs /dev devtmpfs rw,relatime,size=468148k,nr_inodes=117037,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0 tmpfs /etc/machine-id tmpfs ro,mode=755 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 configfs /sys/kernel/config configfs rw,relatime 0 0 /dev/mmcblk0p1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0 ````` Gitea is based in `/var/lib/gitea`, repos are in `/var/lib/gitea/gitea-repositories/{user}`, which is both on the root filesystem. (Random thought: if the repositories were on a noexec filesystem shouldn't the repo home page never update? Because as it is, it updates with the second push, just not with the first one)

GiteaMirror commented

@arount commented on GitHub (Mar 23, 2018):

Fixed for me (because of noexec)

@arount commented on GitHub (Mar 23, 2018): Fixed for me (because of `noexec`)

GiteaMirror commented

2025-11-02 04:02:50 -06:00

@vfricou commented on GitHub (Mar 28, 2018):

Same problem here with upgrade from 1.3.2 to 1.4.0 (stable released), the home repository page update only on second push to repository.

Edit : I'll try with fresh install to test comportment.
Edit 2 : With exact same config, I can't reproduce this issue on new fresh install in v1.4.0.

@vfricou commented on GitHub (Mar 28, 2018): Same problem here with upgrade from 1.3.2 to 1.4.0 (stable released), the home repository page update only on second push to repository. Edit : I'll try with fresh install to test comportment. Edit 2 : With exact same config, I can't reproduce this issue on new fresh install in v1.4.0.

GiteaMirror commented

@lafriks commented on GitHub (Mar 28, 2018):

@vfricou do you see anything bad in gitea.log for first push?

@lafriks commented on GitHub (Mar 28, 2018): @vfricou do you see anything bad in gitea.log for first push?

GiteaMirror commented

2025-11-02 04:02:50 -06:00

@lordlethis commented on GitHub (Mar 28, 2018):

I can reliably reproduce this, but only in Debian Jessie...

Going from the logs I linked to earlier (https://gist.github.com/lordlethis/87ed693593f750077b0096931053288f), if I'm reading this right

Feb 13 16:10:28 arrpie gitea[23613]: [Macaron] 2018-02-13 16:10:28: Started POST /api/internal/push/update for [::1]
...
Feb 13 16:10:28 arrpie gitea[23613]: [git-module] /var/lib/gitea/gitea-repositories/lordlethis/testy.git: git -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= for-each-ref --count=2 --format=%(refname) --contains e8aeda691fd5df1d14c4b140e6f21111b1efed9e refs/heads/
Feb 13 16:10:28 arrpie gitea[23613]: [Macaron] 2018-02-13 16:10:28: Completed POST /api/internal/push/update 500 Internal Server Error in 119.470085ms

there seems to be some failure while running this git command? (It does fail if I try running it manually, because git for-each-ref does not support --contains with git 2.1.4).

@lordlethis commented on GitHub (Mar 28, 2018): I can reliably reproduce this, but only in Debian Jessie... Going from the logs I linked to earlier (https://gist.github.com/lordlethis/87ed693593f750077b0096931053288f), if I'm reading this right ````` Feb 13 16:10:28 arrpie gitea[23613]: [Macaron] 2018-02-13 16:10:28: Started POST /api/internal/push/update for [::1] ... Feb 13 16:10:28 arrpie gitea[23613]: [git-module] /var/lib/gitea/gitea-repositories/lordlethis/testy.git: git -c filter.lfs.required= -c filter.lfs.smudge= -c filter.lfs.clean= for-each-ref --count=2 --format=%(refname) --contains e8aeda691fd5df1d14c4b140e6f21111b1efed9e refs/heads/ Feb 13 16:10:28 arrpie gitea[23613]: [Macaron] 2018-02-13 16:10:28: Completed POST /api/internal/push/update 500 Internal Server Error in 119.470085ms ````` there seems to be some failure while running this git command? (It does fail if I try running it manually, because git for-each-ref does not support --contains with git 2.1.4).

GiteaMirror commented

@lafriks commented on GitHub (Mar 28, 2018):

I will try to reproduce this with Debian 8.10

@lafriks commented on GitHub (Mar 28, 2018): I will try to reproduce this with Debian 8.10

GiteaMirror commented

@oidz1234 commented on GitHub (Mar 29, 2018):

I am having this issue as well

Centos7
latest gitea release
git version 1.8.3.1
Sqlite db

I pushed a local repo with 30 + commits in it.

On first push to gitea nothing seemed to happen on the gitea web interface

Nothing bad on first push in the logs, after second commit to remote repo everything works, again nothing entered into the logs.

@oidz1234 commented on GitHub (Mar 29, 2018): I am having this issue as well Centos7 latest gitea release git version 1.8.3.1 Sqlite db I pushed a local repo with 30 + commits in it. On first push to gitea nothing seemed to happen on the gitea web interface Nothing bad on first push in the logs, after second commit to remote repo everything works, again nothing entered into the logs.

GiteaMirror commented

@vfricou commented on GitHub (Mar 29, 2018):

@lafriks No, I didn't see anything bad… Is the problem… If I see any error or something special, I'll show you…

Effectively, my problem is against on debian jessie release. I'll try to upgrade to stretch release to see if problem persist.

@vfricou commented on GitHub (Mar 29, 2018): @lafriks No, I didn't see anything bad… Is the problem… If I see any error or something special, I'll show you… Effectively, my problem is against on debian jessie release. I'll try to upgrade to stretch release to see if problem persist.

GiteaMirror commented

@vfricou commented on GitHub (Mar 29, 2018):

Okay, I confirm this bug is not present after system upgrade to Debian stretch. Is realy proper to Debian Jessie.

@vfricou commented on GitHub (Mar 29, 2018): Okay, I confirm this bug is not present after system upgrade to Debian stretch. Is realy proper to Debian Jessie.

GiteaMirror commented

@chasgames commented on GitHub (Mar 29, 2018):

Same on centos7

@chasgames commented on GitHub (Mar 29, 2018): Same on centos7

GiteaMirror commented

@mxmehl commented on GitHub (Apr 4, 2018):

I can confirm that the issues persists with Debian Jessie. Cannot test Stretch here.

@mxmehl commented on GitHub (Apr 4, 2018): I can confirm that the issues persists with Debian Jessie. Cannot test Stretch here.

GiteaMirror commented

@awwong1 commented on GitHub (Apr 6, 2018):

I can confirm this issue on a Raspberry Pi 3 running the 1.4.0 release.

git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ uname -a
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ go version
go version go1.9 linux/arm

git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ git log -1
commit 832e2ebe912b10a24fafe4b0d33b4f3e89f6375e
Author: Lauris BH <lauris@nix.lv>
Date:   Sun Mar 25 04:12:48 2018 +0300

    Changelog for release 1.4.0 (#3714)

I'm not sure if the noexec fix applies to me. I am running the gitea service using systemd.

git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ pwd
/home/git/sandbox/src/code.gitea.io/gitea

git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ cat custom/conf/app.ini | grep repository -A 2
[repository]
ROOT = /home/git/gitea-repositories

git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ cat /proc/mounts
/dev/root / ext4 rw,noatime,data=ordered 0 0
devtmpfs /dev devtmpfs rw,relatime,size=492508k,nr_inodes=123127,mode=755 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
proc /proc proc rw,relatime 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0
tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0
tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0
tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0
cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0
cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0
cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0
cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0
cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0
cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0
cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0
tmpfs /etc/machine-id tmpfs ro,mode=755 0 0
systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0
debugfs /sys/kernel/debug debugfs rw,relatime 0 0
mqueue /dev/mqueue mqueue rw,relatime 0 0
configfs /sys/kernel/config configfs rw,relatime 0 0
/dev/mmcblk0p1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0

EDIT: Clarification to noexec

@awwong1 commented on GitHub (Apr 6, 2018): I can confirm this issue on a Raspberry Pi 3 running the 1.4.0 release. ```bash git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ uname -a Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ go version go version go1.9 linux/arm git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ git log -1 commit 832e2ebe912b10a24fafe4b0d33b4f3e89f6375e Author: Lauris BH <lauris@nix.lv> Date: Sun Mar 25 04:12:48 2018 +0300 Changelog for release 1.4.0 (#3714) ``` I'm not sure if the `noexec` fix applies to me. I am running the `gitea` service using systemd. ```bash git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ pwd /home/git/sandbox/src/code.gitea.io/gitea git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ cat custom/conf/app.ini | grep repository -A 2 [repository] ROOT = /home/git/gitea-repositories ``` ``` git@raspberrypi:~/sandbox/src/code.gitea.io/gitea $ cat /proc/mounts /dev/root / ext4 rw,noatime,data=ordered 0 0 devtmpfs /dev devtmpfs rw,relatime,size=492508k,nr_inodes=123127,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 proc /proc proc rw,relatime 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /run tmpfs rw,nosuid,nodev,mode=755 0 0 tmpfs /run/lock tmpfs rw,nosuid,nodev,noexec,relatime,size=5120k 0 0 tmpfs /sys/fs/cgroup tmpfs ro,nosuid,nodev,noexec,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/cpu,cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpu,cpuacct 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0 tmpfs /etc/machine-id tmpfs ro,mode=755 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 debugfs /sys/kernel/debug debugfs rw,relatime 0 0 mqueue /dev/mqueue mqueue rw,relatime 0 0 configfs /sys/kernel/config configfs rw,relatime 0 0 /dev/mmcblk0p1 /boot vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0 ``` EDIT: Clarification to noexec

GiteaMirror commented

@Madmorgan007 commented on GitHub (Apr 16, 2018):

Hi,

quick way to fix this is to open the DB, update is_Bare colom in repository table to 0

SQL code
UPDATE gitea.repository SET is_bare = '0' WHERE repository.id = 11;

@Madmorgan007 commented on GitHub (Apr 16, 2018): Hi, quick way to fix this is to open the DB, update is_Bare colom in repository table to 0 SQL code UPDATE `gitea`.`repository` SET `is_bare` = '0' WHERE `repository`.`id` = 11;

GiteaMirror commented

@neji0924 commented on GitHub (Apr 27, 2018):

@Madmorgan007 fixed for me!

@neji0924 commented on GitHub (Apr 27, 2018): @Madmorgan007 fixed for me!

GiteaMirror commented

@awwong1 commented on GitHub (Apr 27, 2018):

@neji0924 I think you can also make an empty commit. git commit --allow-empty

@awwong1 commented on GitHub (Apr 27, 2018): @neji0924 I think you can also make an empty commit. `git commit --allow-empty`

GiteaMirror commented

@mxmehl commented on GitHub (Apr 28, 2018):

@neji0924 I think you can also make an empty commit. git commit --allow-empty

This, or got an empty git commit --amend and git push -f. This way, you don't have two commits but at the cost of rewriting the Git history.

Do we already know how the bug is caused in Gitea? It has to be some kind of regression between 1.3.3 and 1.4.0

@mxmehl commented on GitHub (Apr 28, 2018): > @neji0924 I think you can also make an empty commit. git commit --allow-empty This, or got an empty `git commit --amend` and `git push -f`. This way, you don't have two commits but at the cost of rewriting the Git history. Do we already know how the bug is caused in Gitea? It has to be some kind of regression between 1.3.3 and 1.4.0

GiteaMirror commented

@mgineer85 commented on GitHub (May 2, 2018):

can confirm this issue, too.
I put gitea on an existing openmediavault3 installation.

pushing another empty commit updated the website at once.

@mgineer85 commented on GitHub (May 2, 2018): can confirm this issue, too. I put gitea on an existing openmediavault3 installation. pushing another empty commit updated the website at once.

GiteaMirror commented

@withings-sas commented on GitHub (May 11, 2018):

had the same issue, I had to run the command from @Madmorgan007 comment to fix it (UPDATE gitea.repository SET is_bare = '0')

@withings-sas commented on GitHub (May 11, 2018): had the same issue, I had to run the command from @Madmorgan007 comment to fix it (UPDATE gitea.repository SET is_bare = '0')

GiteaMirror commented

@IzzySoft commented on GitHub (May 17, 2018):

It does not looks like to be related to the number of commits, but by the fact you pushed only one time (you can create 2 or 10 commits before first push and got the same behavior)

I can absolutely confirm the "related to number of pushes". I've setup 3 repos – one for each machine I've installed etckeeper on. Initialized etckeeper on all 3 machines, pushed. Figured on one server I needed a slight adjustment, so committed that and pushed again. This was the only repo with 2 pushes – and the only one showing content.

So I pulled the UPDATE gitea.repository SET is_bare = '0' trick (as that was the only difference I could see), and it worked for the other two. Unfortunately I found this issue here only afterwards, or I had tried to fully confirm by another push …

Note: No noexec involved here at all (or the one repo with the 2 pushes couldn't have worked automatically either – but I explicitly checked with mount to make sure). Gitea 1.4.0 here if it matters. Cannot remember having seen this with older versions, when I created my other 20 repos.

@IzzySoft commented on GitHub (May 17, 2018): > It does not looks like to be related to the number of commits, but by the fact you pushed only one time (you can create 2 or 10 commits before first push and got the same behavior) I can absolutely confirm the "related to number of pushes". I've setup 3 repos – one for each machine I've installed etckeeper on. Initialized etckeeper on all 3 machines, pushed. Figured on one server I needed a slight adjustment, so committed that and pushed again. This was the only repo with 2 pushes – and the only one showing content. So I pulled the `UPDATE gitea.repository SET is_bare = '0'` trick (as that was the only difference I could see), and it worked for the other two. Unfortunately I found this issue here only afterwards, or I had tried to fully confirm by another push … Note: No `noexec` involved here at all (or the one repo with the 2 pushes couldn't have worked automatically either – but I explicitly checked with `mount` to make sure). Gitea 1.4.0 here if it matters. Cannot remember having seen this with older versions, when I created my other 20 repos.

GiteaMirror commented

2025-11-02 04:02:54 -06:00

@hudecof commented on GitHub (May 24, 2018):

+1 in 1.4.0 and 1.4.1.
I still see empty git repository in UI after first push

@hudecof commented on GitHub (May 24, 2018): +1 in 1.4.0 and 1.4.1. I still see empty git repository in UI after first push

GiteaMirror commented

@oidz1234 commented on GitHub (May 24, 2018):

I still have the issue on latest release

@oidz1234 commented on GitHub (May 24, 2018): I still have the issue on latest release

GiteaMirror commented

2025-11-02 04:02:54 -06:00

@daviian commented on GitHub (May 24, 2018):

@IzzySoft @hudecof @oidz1234 I can't reproduce that with 1.4.0

Can you describe exactly what steps you do?

If I do:

create repo without initial readme
follow first instructions presented using http method
refresh page
normal repository view is shown

@daviian commented on GitHub (May 24, 2018): @IzzySoft @hudecof @oidz1234 I can't reproduce that with 1.4.0 Can you describe exactly what steps you do? If I do: 1. create repo without initial readme 2. follow first instructions presented using http method 3. refresh page 4. normal repository view is shown

GiteaMirror commented

2025-11-02 04:02:54 -06:00

@IzzySoft commented on GitHub (May 24, 2018):

@daviian I'm currently not "in reach" of my installation to check again – but what I did is:

initialized a repo on "some machine"
initial commit (machine A; on machine B it have been 2 commits)
create repo without initial readme (in Gitea). Initial instructions were shown.
back on machine A/B, pushed to the newly created bare on Gitea
web page for the two repos still showed initial instructions – after page reload as well as after calling up the page with a different browser (so it's definitely not browser cache)
shutdown Gitea, manually ran UPDATE gitea.repository SET is_bare = '0', startup Gitea again
now browser showed repo contents.

As pointed out, there was a "machine C" where after step 4 I created another commit and pushed. That one went straight to step 7 (i.e. worked as expected).

@IzzySoft commented on GitHub (May 24, 2018): @daviian I'm currently not "in reach" of my installation to check again – but what I did is: 1. initialized a repo on "some machine" 1. initial commit (machine A; on machine B it have been 2 commits) 1. create repo without initial readme (in Gitea). Initial instructions were shown. 1. back on machine A/B, pushed to the newly created bare on Gitea 1. web page for the two repos still showed initial instructions – after page reload as well as after calling up the page with a different browser (so it's definitely not browser cache) 1. shutdown Gitea, manually ran `UPDATE gitea.repository SET is_bare = '0'`, startup Gitea again 1. now browser showed repo contents. As pointed out, there was a "machine C" where after step 4 I created another commit and pushed. That one went straight to step 7 (i.e. worked as expected).

GiteaMirror commented

@daviian commented on GitHub (May 24, 2018):

@IzzySoft Tried it that way but it simply always works for me 🤔

@daviian commented on GitHub (May 24, 2018): @IzzySoft Tried it that way but it simply always works for me :thinking:

GiteaMirror commented

@hudecof commented on GitHub (May 24, 2018):

@IzzySoft described my workflow

@hudecof commented on GitHub (May 24, 2018): @IzzySoft described my workflow

GiteaMirror commented

@hudecof commented on GitHub (May 24, 2018):

strange, it works as expected right now. I was fighint with one repo all the day

@hudecof commented on GitHub (May 24, 2018): strange, it works as expected right now. I was fighint with one repo all the day

GiteaMirror commented

@IzzySoft commented on GitHub (May 24, 2018):

@daviian let's wait for @oidz1234 to report back as well. If I'm the only one left having this issue: I know a work-around (as described). It's not that often that I need to create a new repo in Gitea, so for those few times I can certainly live with that (but will keep an eye on it whenever I create a new repo; maybe we all missed some detail). Though of course it would be nice if it were solved 😉

Just in case the local git version (on the machine running Gitea) is relevant: 2.1.4 here (ARMv7 – it's running on a BananaPi).

@IzzySoft commented on GitHub (May 24, 2018): @daviian let's wait for @oidz1234 to report back as well. If I'm the only one left having this issue: I know a work-around (as described). It's not that often that I need to create a new repo in Gitea, so for those few times I can certainly live with that (but will keep an eye on it whenever I create a new repo; maybe we all missed some detail). Though of course it would be nice if it were solved :wink: Just in case the local git version (on the machine running Gitea) is relevant: 2.1.4 here (ARMv7 – it's running on a BananaPi).

GiteaMirror commented

@oidz1234 commented on GitHub (May 24, 2018):

First test SSH:

Create git repo in gitea web interface
Push already existing repo from local machine to remote gitea instance
Nothing happens on gitea interface. Tried multiple browsers etc.

Test 2 HTTP:

Same tests, same results. Nothing on gitea web interface.

Running the below does fix it for the repository.

UPDATE gitea.repository SET is_bare = '0'

@oidz1234 commented on GitHub (May 24, 2018): First test SSH: 1. Create git repo in gitea web interface 2. Push already existing repo from local machine to remote gitea instance 3. Nothing happens on gitea interface. Tried multiple browsers etc. Test 2 HTTP: Same tests, same results. Nothing on gitea web interface. Running the below does fix it for the repository. ``UPDATE gitea.repository SET is_bare = '0'``

GiteaMirror commented

@daviian commented on GitHub (May 24, 2018):

@IzzySoft I beliebe we all want this bug to be fixed, as long as it indeed is a bug 😂

@oidz1234 I've tested it that way too, but still works for me 😞

@daviian commented on GitHub (May 24, 2018): @IzzySoft I beliebe we all want this bug to be fixed, as long as it indeed is a bug :joy: @oidz1234 I've tested it that way too, but still works for me :disappointed:

GiteaMirror commented

@lunny commented on GitHub (May 24, 2018):

any error logs on console or file?

@lunny commented on GitHub (May 24, 2018): any error logs on console or file?

GiteaMirror commented

@oidz1234 commented on GitHub (May 24, 2018):

Nope no errors. Any log files you need a dump off ?

@oidz1234 commented on GitHub (May 24, 2018): Nope no errors. Any log files you need a dump off ?

GiteaMirror commented

@parsley42 commented on GitHub (May 24, 2018):

Check your git version; this stems from git for-each-ref in the git package. I added an extra debugging log line to get this nugget in my log:

gitea[31211]: [Macaron] 2018-05-24 13:53:56: Completed POST /api/internal/push/update 500 Internal Server Error in 12.686445ms
gitea[31211]: 2018/05/24 13:53:56 [...acaron.v1/context.go:79 Invoke()] [E] newCommit.CommitsBeforeLimit: exit status 129 - error: unknown option `contains'
gitea[31211]: usage: git for-each-ref [options] [<pattern>]
gitea[31211]: -s, --shell           quote placeholders suitably for shells
...

Even before that, though, I was seeing [Macaron] 2018-05-24 13:53:56: Completed POST /api/internal/push/update 500 Internal Server Error - not sure why others aren't seeing that.

For our CentOS system, I just installed git2u from IUS (https://ius.io).

@parsley42 commented on GitHub (May 24, 2018): Check your git version; this stems from `git for-each-ref` in the `git` package. I added an extra debugging log line to get this nugget in my log: ``` gitea[31211]: [Macaron] 2018-05-24 13:53:56: Completed POST /api/internal/push/update 500 Internal Server Error in 12.686445ms gitea[31211]: 2018/05/24 13:53:56 [...acaron.v1/context.go:79 Invoke()] [E] newCommit.CommitsBeforeLimit: exit status 129 - error: unknown option `contains' gitea[31211]: usage: git for-each-ref [options] [<pattern>] gitea[31211]: -s, --shell quote placeholders suitably for shells ... ``` Even before that, though, I was seeing `[Macaron] 2018-05-24 13:53:56: Completed POST /api/internal/push/update 500 Internal Server Error` - not sure why others aren't seeing that. For our CentOS system, I just installed `git2u` from IUS (https://ius.io).

GiteaMirror commented

@mgineer85 commented on GitHub (May 24, 2018):

@parsley42 thanks for finding out.
I had problems with that, too. I checked my git version on my openmediavault (debian jessie) and it was 2.1.4 (from 2014). just updated to git 2.17.0.
works perfect from first commit on!

@mgineer85 commented on GitHub (May 24, 2018): @parsley42 thanks for finding out. I had problems with that, too. I checked my git version on my openmediavault (debian jessie) and it was 2.1.4 (from 2014). just updated to git 2.17.0. works perfect from first commit on!

GiteaMirror commented

@daviian commented on GitHub (May 24, 2018):

Hey guys,

I've submitted a PR to fix this. Would appreciate if someone of you guys having troubles can test this and if this fixes it!

@daviian commented on GitHub (May 24, 2018): Hey guys, I've submitted a PR to fix this. Would appreciate if someone of you guys having troubles can test this and if this fixes it!

GiteaMirror commented

@IzzySoft commented on GitHub (May 25, 2018):

@mgrl Jessie and Git 2.1.4 here as well. How did you update git? 2.1.4 is the latest the official repo provides.

@IzzySoft commented on GitHub (May 25, 2018): @mgrl Jessie and Git 2.1.4 here as well. How did you update git? 2.1.4 is the latest the official repo provides.

GiteaMirror commented

@mgineer85 commented on GitHub (May 25, 2018):

Added some testing repos somehow I found on stackexchange ;)

Am 25. Mai 2018 07:59:57 schrieb Izzy notifications@github.com:

@mgrl Jessie and Git 2.1.4 here as well. How did you update git? 2.1.4 is
the latest the official repo provides.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@mgineer85 commented on GitHub (May 25, 2018): Added some testing repos somehow I found on stackexchange ;) Am 25. Mai 2018 07:59:57 schrieb Izzy <notifications@github.com>: > @mgrl Jessie and Git 2.1.4 here as well. How did you update git? 2.1.4 is > the latest the official repo provides. > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub, or mute the thread.

GiteaMirror commented

@hudecof commented on GitHub (May 25, 2018):

I discovered this bug on 1.4.0 version. I upgraded to the 1.4.1 yetsreday, but I need to do manual fix to resolve it. All tests I did was on new 1.4.1 version.

I'm using latest /all updates/ Debian 9.4 (stretch)

@hudecof commented on GitHub (May 25, 2018): I discovered this bug on `1.4.0` version. I upgraded to the `1.4.1` yetsreday, but I need to do manual fix to resolve it. All tests I did was on new `1.4.1` version. I'm using latest /all updates/ **Debian 9.4 (stretch)**

GiteaMirror commented

@daviian commented on GitHub (May 25, 2018):

@hudecof Can you provide the gitea.log like @parsley42

@daviian commented on GitHub (May 25, 2018): @hudecof Can you provide the gitea.log like @parsley42

GiteaMirror commented

@hudecof commented on GitHub (May 25, 2018):

@daviian there's nothing in my gitea.log file ;( just [I] messages

@hudecof commented on GitHub (May 25, 2018): @daviian there's nothing in my gitea.log file ;( just `[I]` messages

GiteaMirror commented

@daviian commented on GitHub (May 25, 2018):

@hudecof Too bad. Debian stretch provides git in version 2.11.0 so the git for-each-ref command should definitely work.

Can you run the git command manually on this system on a repo?
git for-each-ref --count=10 --format='%(refname)' --contains <any-commit-hash> /refs/heads/

@daviian commented on GitHub (May 25, 2018): @hudecof Too bad. Debian stretch provides git in version 2.11.0 so the `git for-each-ref` command should definitely work. Can you run the git command manually on this system on a repo? `git for-each-ref --count=10 --format='%(refname)' --contains <any-commit-hash> /refs/heads/`

GiteaMirror commented

@daviian commented on GitHub (May 27, 2018):

@mgrl @IzzySoft @parsley42
Would you be so kind as to test if the issue is solved with the newly created PR?

@daviian commented on GitHub (May 27, 2018): @mgrl @IzzySoft @parsley42 Would you be so kind as to test if the issue is solved with the newly created PR?

GiteaMirror commented

@IzzySoft commented on GitHub (May 27, 2018):

@daviian only after it has been released, sorry. I'm running the "one-off binary" on a Pi, no way to use Go directly or to compile it.

@IzzySoft commented on GitHub (May 27, 2018): @daviian only after it has been released, sorry. I'm running the "one-off binary" on a Pi, no way to use Go directly or to compile it.

GiteaMirror commented

@daviian commented on GitHub (May 27, 2018):

@IzzySoft We also build latest binaries from master branch, see https://dl.gitea.io/gitea/master/
If you wait til tomorrow the newest commits should be released as well.

@daviian commented on GitHub (May 27, 2018): @IzzySoft We also build latest binaries from master branch, see https://dl.gitea.io/gitea/master/ If you wait til tomorrow the newest commits should be released as well.

GiteaMirror commented