Repositories Always Show Quick-Start Guide #1125

@ghost commented on GitHub (Oct 10, 2017):

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.

@ghost commented on GitHub (Oct 10, 2017): So, exploring the codebase a little, the mistaken template rendering is happening [here](https://github.com/go-gitea/gitea/blob/1ad902d5298202d5be14fd5a9c8ed6ce781a23c8/routers/repo/view.go#L292). 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.

GiteaMirror commented

@ghost commented on GitHub (Oct 10, 2017):

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.

@ghost commented on GitHub (Oct 10, 2017): 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.

GiteaMirror commented

@lafriks commented on GitHub (Oct 21, 2017):

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

@lafriks commented on GitHub (Oct 21, 2017): @cathalgarvey can it be that it was just cached by caddy somehow as I can not reproduce such issue

GiteaMirror commented

@ghost commented on GitHub (Oct 21, 2017):

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 notifications@github.com 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.

@ghost commented on GitHub (Oct 21, 2017): 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 <notifications@github.com> 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.

GiteaMirror commented

@ghost commented on GitHub (Nov 14, 2017):

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

@ghost commented on GitHub (Nov 14, 2017): 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. :)

GiteaMirror commented

@smaeul commented on GitHub (Jan 5, 2018):

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

@smaeul commented on GitHub (Jan 5, 2018): See my comment on https://github.com/go-gitea/gitea/issues/2898. Maybe it's the same issue, or helps you find yours.

GiteaMirror commented

@ghost commented on GitHub (Jan 5, 2018):

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?

@ghost commented on GitHub (Jan 5, 2018): 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?

GiteaMirror commented

@lunny commented on GitHub (Jan 5, 2018):

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

@lunny commented on GitHub (Jan 5, 2018): @cathalgarvey maybe a PR to check if there is exec permission on the repo's hooks.

GiteaMirror commented

@ghost commented on GitHub (Jan 8, 2018):

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!

@ghost commented on GitHub (Jan 8, 2018): 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!

GiteaMirror commented

@James-E-A commented on GitHub (Jan 14, 2019):

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.

@James-E-A commented on GitHub (Jan 14, 2019): 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.

GiteaMirror commented

@James-E-A commented on GitHub (Jan 14, 2019):

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

@James-E-A commented on GitHub (Jan 14, 2019): 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 ````

GiteaMirror commented

@nandoflorestan commented on GitHub (Aug 19, 2019):

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.

@nandoflorestan commented on GitHub (Aug 19, 2019): 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.

GiteaMirror commented

@vladtcvs commented on GitHub (Nov 13, 2019):

Still present.
Postgresql, gitea 1.9.5, git 2.24.0

@vladtcvs commented on GitHub (Nov 13, 2019): Still present. Postgresql, gitea 1.9.5, git 2.24.0

GiteaMirror commented

@zeripath commented on GitHub (Nov 14, 2019):

@vladtcvs What do you mean it is still present?

@zeripath commented on GitHub (Nov 14, 2019): @vladtcvs What do you mean it is still present?

GiteaMirror commented

@Flameborn commented on GitHub (Nov 17, 2019):

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.

@Flameborn commented on GitHub (Nov 17, 2019): 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.

GiteaMirror commented

@guillep2k commented on GitHub (Nov 17, 2019):

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

@guillep2k commented on GitHub (Nov 17, 2019): @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).

GiteaMirror commented

@Flameborn commented on GitHub (Nov 17, 2019):

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 notifications@github.com 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.

@Flameborn commented on GitHub (Nov 17, 2019): 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 <notifications@github.com> 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>. >

GiteaMirror commented

@zeripath commented on GitHub (Nov 17, 2019):

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

@zeripath commented on GitHub (Nov 17, 2019): @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.)

GiteaMirror commented