Gitea: Repositories Always Show Quick-Start Guide

[cathalgarvey]

• Gitea version (or commit ref): 26e49b8
• Git version: 26e49b8 (?)
• Operating system: Ubuntu Linux x86_64
• Database (use [x]):
  
  
  
  • [ ] PostgreSQL
  
  
  • [ ] MySQL
  
  
  • [ ] MSSQL
  
  
  • [x] SQLite
  
  
• Can you reproduce the bug at https://try.gitea.io:
  
  
  
  • [ ] Yes (provide example URL)
  
  
  • [x] No
  
  
  • [ ] Not relevant
  
  
• Log gist:

Description

I'm using a dockerised gitea setup, approximately according to the normal instructions. I set up a /gitea path and I have it proxied through Caddy with the /caddy path removed (this was necessary to get Gitea to work, sadly; it doesn't like not being on the root?

Everything now seems to work OK, except that when I create a repository and push to it, the webapp continues to display the "Quick Guide" permanently. I looked in browser console; everything's loading OK. If I pull from the repo in another directory, then it's pulling the files correctly; so the SSH back-end is working fine, too. But the webapp is not able to detect the new information, it seems?

I'm wondering whether this is a backend:frontend confusion caused by my configuration. I have the ports forwarded to different numbers, so in my app.ini file, my "SSH_DOMAIN" setting is the domain name and the externally facing port, not 10022, and the DOMAIN setting is also the domain with this port appended.. I've since learned that ssh paths like domain.tld:23:user/path don't work, so nonstandard ports require a git config entry. Is it possible that Gitea is using the "SSH_DOMAIN" setting to access its own back-end by the wrong port; e.g. 23 rather than 10022?

Screenshots

Nothing looks unusual, it's just the standard Quick Guide screen for a new repo.

[cathalgarvey]

So, exploring the codebase a little, the mistaken template rendering is happening here.

That implies that in Go-land, the repo isn't getting the same information as the repo in the clone-path.

But, Go-land was able to initialise the repository correctly so that I could push/pull it.

I'll continue by digging into the logic behind ctx.Repo.Repository.IsBare and see if I can learn more.
Meanwhile if anyone else already knows what's going on here I'd love the assist.

[cathalgarvey]

So, I fixed this on a single-repository basis by opening the SQLite database and manually setting the "is_bare" field to 0; the repository in question now displays correctly. But, whatever caused this issue hasn't gone away, so I won't close this issue. I've just worked around it, for now.

[lafriks]

@cathalgarvey can it be that it was just cached by caddy somehow as I can not reproduce such issue

[cathalgarvey]

Thanks, but I'm sure it was not that. I looked at the database entry and it was still marked as an empty repository even after several SSH pushes.

On 21 October 2017 16:29:02 GMT+01:00, Lauris BH [e-mail] wrote:

@cathalgarvey can it be that it was just cached by caddy somehow as I
can not reproduce such issue

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/go-gitea/gitea/issues/2665#issuecomment-338410336

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[cathalgarvey]

Still experiencing this problem, but for others who are having this problem (like #2898) - the patch is to open the Database and run UPDATE repository SET is_bare = 0;. You're trading one problem for another, because when you do this, empty repositories will show a 500 error instead of the quickstart guide, until you make a push. But, I consider that a better situation. :)

[smaeul]

See my comment on https://github.com/go-gitea/gitea/issues/2898. Maybe it's the same issue, or helps you find yours.

[cathalgarvey]

Wow, thanks for the detailed writeup @smaeul - This could completely explain my issue, I've got my Docker volumes mounted from a USB drive that's probably noexec, and if noexec propagates into a docker volume (for security reasons, it surely would) then that would explain it!

If so, I can fix my issue.. but perhaps Gitea should have a fallback method to mark repos as "non empty" in the absence of git hooks, and perhaps even a way to detect noexec'd hooks and warn the user, if they are relevant?

[lunny]

@cathalgarvey maybe a PR to check if there is exec permission on the repo's hooks.

[cathalgarvey]

I edited my fstab to remove the noexec flag from the drive where my Docker mounts are located, and the problem is resolved, for me. Thanks @smaeul for your writeup in #2898!

[JamesTheAwesomeDude]

This issue is still present...

• Ubuntu 18.04
• Git 2.17.1
• Gitea 1.6.1 and/or 1.7.0-rc2 (precomp executable binary)

On this system, ensuring the repo area was executable (it already was) did NOT fix the bug:

root@tritium:/var/storage/gitea/repositories# touch test root@tritium:/var/storage/gitea/repositories# chmod +x test root@tritium:/var/storage/gitea/repositories# ls -l total 0 drwxrwxr-x 1 git git 170 Jan 14 20:21 james drwxrwxr-x 1 git git 44 Dec 14 19:51 mirrors -rwxr-xr-x 1 root root 0 Jan 14 20:52 test root@tritium:/var/storage/gitea/repositories#

despite pushing commits to two branches, I'm still getting the quickstart guide when logged in / "This repository does not contain any content." when logged out.

[JamesTheAwesomeDude]

And the canned command(s) for anyone else still affected, stumbling across this thread and (as was I) inexperienced with sqlite3 is:

$ service gitea stop #or whatever $ sqlite3 "${GITEA_WORK_DIR}/data/gitea.db" #or wherever gitea.db lies sqlite> SELECT * FROM repository ; -- FAR-LEFT COLUMN OF THE REPO IS THE ID -- REPLACE 12345 WITH YOUR ID: sqlite> UPDATE repository SET is_bare = 0 WHERE id = 12345 ; sqlite> <<Ctrl-D or other EOF>> $ service gitea start

[nandoflorestan]

A heads up for other people reading this:

I am running gitea 1.9.1 and by now the is_bare column no longer exists in the repository table, but you know what? The column is_empty exists and setting it to 0 achieves the same as before.

[vladtcvs]

Still present.
Postgresql, gitea 1.9.5, git 2.24.0

[zeripath]

@vladtcvs What do you mean it is still present?

[Flameborn]

The issue is still present here as well, via Gitea 1.9.5.

I am running on Arch linux Arm via a custom-compiled Go binary (not dockerized).

I created a fresh repo, and chose to not initialize it. When pushing to it, Gitea still displays the quick guide, despite a few pushes, and I am not seeing files via the web UI.

[guillep2k]

@Flameborn Your problem may be due to a different cause than that of this issue. It's most probably a configuration problem, but if it isn't please try opening a new issue describing your setup. Some things to check for:

• Make sure to re-initialize all pre-receive, etc git hooks (there's an option in the admin menu for that).
• Make sure to re-initialize the authorized_keys file (there's also an option in the admin menu for that).

[Flameborn]

Thanks. I will run through and check if any of these fixes my issue.

It is a fresh Gitea install, I’ll see if I can reproduce it on a different machine as well.

On 2019. Nov 17., at 19:09, guillep2k [e-mail] wrote:

@Flameborn https://github.com/Flameborn Your problem may be due to a different cause than that of this issue. It's most probably a configuration problem, but if it isn't please try opening a new issue describing your setup. Some things to check for:

Make sure to re-initialize all pre-receive, etc git hooks (there's an option in the admin menu for that).
Make sure to re-initialize the authorized_keys file (there's also an option in the admin menu for that).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/go-gitea/gitea/issues/2665?email_source=notifications&email_token=AAHLD4APJLDD5T6TX6X3WLLQUGCELA5CNFSM4D6A7JDKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEISEJQ#issuecomment-554770982, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHLD4GTCKZ2RZKWPL7IK23QUGCELANCNFSM4D6A7JDA.

[zeripath]

@Flameborn how are you pushing to these repos?

Are you pushing locally direct to their file path and not through Gitea? If so that's your problem - that is not supported and finally in 1.11 it will tell you that.

If not are your repositories on a non exec partition? Because then hooks would not run and Gitea would have no way of knowing that the data had changed. (Well it could if it read the repo but, that's the architecture we have...) Again putting Gitea repos on non exec partitions is not supported. (Although I do have some ideas about how this could be done.)

[Flameborn]

@guillep2k I have updated to the Arm build of Gitea v1.10.0, unfortunately the issue still persists after running the suggested maintenance tasks.
I temporarily managed to modify the database to make the is_empty field zero, however, this results in other issues (see below). I am not storing Gitea data on a noexec partition. First, I used an SD card and stored the repos on root, then I moved the repos directory to a USB hard drive, changing the repo path respectively in the config file.

I am not sure if this is a configuration issue, but I am happy to raise a new one, if this helps, to not clutter up this one.

@zeripath No, I am pushing via HTTPS, using Gitea's suggested URL for the repo. I discovered since then that web hooks do not seem to work, either, they do not seem to fire on a push event. They work flawlessly when I hit the test button. This is via Caddy and the Git plugin, running on a different server.