Respository's home page not updated after first push #3458

arount · 2018-02-05T13:57:56Z

Gitea version (or commit ref): 1.4.0+rc1
Git version: 1.7.10.4
Operating system: debian 7.11 (wheezy)
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

In brief

Repository's home page not updated after first push.

Reproduce

On vagrant, host: ubuntu 17.10, guest: debian 7.11

On your fresh 1.4.0+rc1 version of Gitea create a regular user let's say spam and login
Create a new repo, let's say eggnbacon.
Clone this repo (only tested with http..) on your local git clone http://192.168.100.10:3000/spam/eggnbacon /tmp/eggnbacon (obviously this IP works on my setup only).
Create new file and commit cd /tmp/eggnbacon && touch yay && git add yay && git commit -m "yay".
Push git push origin master, type credentials, validate.
Check http://192.168.100.10:3000/spam/eggnbacon (still looks like a brand new repo).
Create any kind of new commit, add, commit, push: Frontend updated.

Insights

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)
"content", "code", does not change anything, same workaround with git commit --allow-empty -m "SPAM!" does the exact same.
git push -f after first push (so Everything up-to-date) doesn't change anything (as expected..)

Let's be honest

I have to admit Gitea is grumbling at me:

[...io/gitea/cmd/hook.go:66 hookSetup()] [E] LFS server support needs at least Git v2.1.2

When I push. But it grumbles always that, not only on first push, so I'm not sure it's related.

Hope to not report something already reported, I've didn't digged in all issues :/

The text was updated successfully, but these errors were encountered:

vfricou · 2018-02-05T15:00:48Z

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

lafriks · 2018-02-05T20:40:57Z

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

arount · 2018-02-06T07:58:53Z

@lafriks No, I cannot

aligator · 2018-02-09T11:28:17Z

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

Here is a related issue:
#2898

lordlethis · 2018-02-13T14:21:41Z

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

lafriks · 2018-02-13T14:45:25Z

@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

lordlethis · 2018-02-13T15:45:18Z

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?

Yrek · 2018-02-21T17:34:32Z

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.

lunny · 2018-02-22T06:07:48Z

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

lordlethis · 2018-02-26T07:50:54Z

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 · 2018-02-26T21:49:38Z

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 :-)

lafriks · 2018-03-21T20:18:03Z

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

NyxCode · 2018-03-21T20:53:19Z

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!

mxmehl · 2018-03-23T11:34:11Z

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

lordlethis · 2018-03-23T11:58:56Z

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)

arount · 2018-03-23T14:16:47Z

Fixed for me (because of noexec)

vfricou · 2018-03-28T14:29:27Z

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.

lafriks · 2018-03-28T17:49:37Z

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

lordlethis · 2018-03-28T18:45:17Z

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).

lafriks · 2018-03-28T19:28:44Z

I will try to reproduce this with Debian 8.10

oidz1234 · 2018-03-29T10:23:58Z

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.

vfricou · 2018-03-29T14:30:33Z

@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 · 2018-03-29T15:06:45Z

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

IzzySoft · 2018-05-24T14:30:45Z

@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).

oidz1234 · 2018-05-24T14:50:08Z

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'

daviian · 2018-05-24T15:39:23Z

@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 😞

lunny · 2018-05-24T15:43:02Z

any error logs on console or file?

oidz1234 · 2018-05-24T15:50:34Z

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

parsley42 · 2018-05-24T19:18:49Z

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).

mgineer85 · 2018-05-24T20:12:32Z

@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!

daviian · 2018-05-24T21:54:40Z

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!

IzzySoft · 2018-05-25T05:59:42Z

@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.

mgineer85 · 2018-05-25T06:16:41Z

Added some testing repos somehow I found on stackexchange ;) Am 25. Mai 2018 07:59:57 schrieb Izzy <[email protected]>:

…

@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.

hudecof · 2018-05-25T07:41:57Z

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)

daviian · 2018-05-25T08:01:59Z

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

hudecof · 2018-05-25T08:14:36Z

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

daviian · 2018-05-25T08:17:53Z

@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 · 2018-05-27T18:38:12Z

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

IzzySoft · 2018-05-27T20:17:41Z

@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.

daviian · 2018-05-27T20:26:41Z

@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.

monkeyhybrid · 2018-05-28T18:58:24Z

@daviian I was also experiencing this issue and can confirm, for me at least, it is solved with the latest master build (05/28/2018 03:48:12 PM).

This is on Debian Jessie host, with Git 2.1.4.

daviian · 2018-05-28T21:19:04Z

@monkeyhybrid That's really great news :)

metalbote · 2019-02-26T00:15:04Z

I am running latest gitea in docker, and seeing this issue as well. The mentioned fix with update is_bare cannot be applied because there isn't a is_bare column in table repositories.... workaround withgit commit --amend && git push -fetc. works

Note: UPDATE gitea.repository SET is_empty = '0' is now the clue

nandoflorestan · 2019-08-19T17:57:55Z

OK, so why is an issue that is seen repetitively (I am also affected, and noexec isn't it) appearing as CLOSED???

When converting a `repo_model.Repository` to `api.Repository`, copy the `ObjectFormatName` field too. Fixes go-gitea#3458. Signed-off-by: Gergely Nagy <[email protected]> (cherry picked from commit 2385f3c)

lafriks added the type/bug label Mar 6, 2018

lafriks added this to the 1.4.0 milestone Mar 6, 2018

lafriks mentioned this issue Mar 6, 2018

Git commits refuse to show up in the web interface #3639

Closed

7 tasks

lafriks added the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label Mar 21, 2018

lafriks removed the issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail label Mar 23, 2018

lafriks modified the milestones: 1.4.0, 1.5.0 Mar 23, 2018

mibcat mentioned this issue May 24, 2018

Repo names are not case-sensitive #4011

Closed

7 tasks

daviian mentioned this issue May 24, 2018

fix git version below 2.7 go-gitea/git#119

Merged

daviian mentioned this issue May 27, 2018

update git vendor #4059

Merged

lafriks closed this as completed in #4059 May 27, 2018

daviian mentioned this issue Jun 5, 2018

Non-empty repository is shown as empty #4134

Closed

7 tasks

irrgit mentioned this issue Nov 21, 2018

Cannot clone imported local path repository #5374

Closed

5 tasks

FloMiau mentioned this issue Feb 2, 2019

Respository's home page not updated after first push #5933

Closed

7 tasks

go-gitea locked and limited conversation to collaborators Nov 24, 2020

Respository's home page not updated after first push #3458

Respository's home page not updated after first push #3458

Comments

arount commented Feb 5, 2018 • edited Loading

Description

In brief

Reproduce

Insights

Let's be honest

vfricou commented Feb 5, 2018 • edited Loading

lafriks commented Feb 5, 2018

arount commented Feb 6, 2018

aligator commented Feb 9, 2018

lordlethis commented Feb 13, 2018

lafriks commented Feb 13, 2018

lordlethis commented Feb 13, 2018

Yrek commented Feb 21, 2018

lunny commented Feb 22, 2018

lordlethis commented Feb 26, 2018

lordlethis commented Feb 26, 2018

Setup

Gitea Setup Page

Database

Optional

Admin account

Issue Reproduction

lafriks commented Mar 21, 2018 • edited Loading

NyxCode commented Mar 21, 2018

mxmehl commented Mar 23, 2018 • edited Loading

lordlethis commented Mar 23, 2018

arount commented Mar 23, 2018 • edited Loading

vfricou commented Mar 28, 2018 • edited Loading

lafriks commented Mar 28, 2018

lordlethis commented Mar 28, 2018

lafriks commented Mar 28, 2018

oidz1234 commented Mar 29, 2018 • edited Loading

vfricou commented Mar 29, 2018 • edited Loading

vfricou commented Mar 29, 2018

IzzySoft commented May 24, 2018

oidz1234 commented May 24, 2018

daviian commented May 24, 2018

lunny commented May 24, 2018

oidz1234 commented May 24, 2018

parsley42 commented May 24, 2018

mgineer85 commented May 24, 2018

daviian commented May 24, 2018

IzzySoft commented May 25, 2018

mgineer85 commented May 25, 2018 via email

hudecof commented May 25, 2018 • edited Loading

daviian commented May 25, 2018

hudecof commented May 25, 2018

daviian commented May 25, 2018 • edited Loading

daviian commented May 27, 2018

IzzySoft commented May 27, 2018

daviian commented May 27, 2018

monkeyhybrid commented May 28, 2018

daviian commented May 28, 2018

metalbote commented Feb 26, 2019

nandoflorestan commented Aug 19, 2019

arount commented Feb 5, 2018 •

edited

Loading

vfricou commented Feb 5, 2018 •

edited

Loading

lafriks commented Mar 21, 2018 •

edited

Loading

mxmehl commented Mar 23, 2018 •

edited

Loading

arount commented Mar 23, 2018 •

edited

Loading

vfricou commented Mar 28, 2018 •

edited

Loading

oidz1234 commented Mar 29, 2018 •

edited

Loading

vfricou commented Mar 29, 2018 •

edited

Loading

hudecof commented May 25, 2018 •

edited

Loading

daviian commented May 25, 2018 •

edited

Loading