When creating repo without init it shows still howto

[ronnicek]

• Gitea version (or commit ref): 5abd1d2
• Git version: git-2.13.5-r0 (on server, git version 2.15.0.windows.1 on client)
• Operating system: Alpine (Docker image)
• 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:
  https://ncry.pt/p/VfKn#hZGWhGd1lY4mCeABs78BHL-Kn570v07pvFC9Fy2htjM

Description

Using latest gitea/gitea docker image. When I create new repository, but do not initialize it on server it shows howto push it from client. So I create repository, add all files, commit it to git, push it to remote according to howto but nothing shows on web (but code is there) - I tried to clone files locally to different folder. On Discord with lafriks we find out that I have to change is_bare to f in postgres then it's working, but he was not able to reproduce it (and for him it changes to is_bare to f when he push something)

Screenshots

[lunny]

Can not reproduce that locally.

[ronnicek]

Is there any way how I can debug it more from my side?

[lunny]

Could you find the xorm.log to put it also on gist?

[ghost]

I'm still having this issue over at #2665 - You can fix it for individual repos by editing your database manually, but I still haven't figured out where the error's coming from.

[ronnicek]

Here is the log: https://ncry.pt/p/ugKn#B9sqCgoGCJzWgHYb-GljnXP20lKkGDxfr9DrcsWBrws

@cathalgarvey yep, I know you can fix it manually.. bt that´s actually not what I am looking for :))

[smaeul]

repo.IsBare is only updated in once place, in CommitRepoAction:

gitea/models/action.go

Line 527 in f2e20c8

repo.IsBare = repo.IsBare && opts.Commits.Len <= 0

This function is called by models.pushUpdate, which is called by models.PushUpdate, which is the implementation of the internal API endpoint /push/update, created in 1773e88. Once again this is only called from one place:

gitea/cmd/hook.go

Line 203 in 9ddbbd9

if err := private.PushUpdate(models.PushUpdateOptions{

which is the implementation for the gitea hook command. This command is run from the $REPO/hooks/post-receive.d/gitea script, which is called from the $REPO/hooks/post-receive wrapper, which is (finally) run by git when pushing over ssh.

This means that if for some reason git hooks are not getting called, or some program they depend on is missing, the IsBare state of the repository will never get updated in the web UI.

In my case the problem was having my repo storage on a ZFS dataset mounted noexec. Since git has a "feature" of treating non-executable hooks as disabled, and noexec appears exactly as if execute permission was missing from the file, there's no warning message from git that the hook is ignored.

After remounting the filesystem exec and pushing new commits (by deleting and recreating a branch), the web UI updated as expected.

[ronnicek]

Hi @smaeul,

Wow, such a detailed and great explanation. Many thanks! Yes, I have filesystem mounted with noexec, so that could be the issue. I will give it a try tonight and report if it's working or not.

[ghost]

Same error here. I push in a bare repo via HTTP, not via SSH.

So I need to update the bare flag manually. Is here a solution for this?

[JohannesBauer97]

Same error

[abatkin]

I seem to be able to reproduce this. But no Docker and no crazy filesystems (regular ext4, no special mount options). It's late now, will see what I can figure out another day.

[abatkin]

This has to do with git version, and gitea is broken on older versions.

On a Centos 7 box, git (1.8.3.1) does not support the --contains option to git for-each-ref. Gitea uses this internally for something. There's also probably some type of bug with Gitea itself, since the command must be failing, but the logs (even in Trace mode, but you'd think it should be there even in Info) say nothing.

Gitea runs something like:

git for-each-ref --count=2 '--format=%(refname)' --contains ea7715eb54ccbe0d0e53afa9889c4406a1d2b2c2 refs/heads/

If you replace the ref with a real ref, and run on a "modern" git, it will work, but with an older git, it will fail (and yes, with a non-zero exit code).

The only hint that something is going wrong in Gitea is, if you run with log level Trace, something that looks like:

[Macaron] 2018-06-04 02:39:03: Completed POST /api/internal/push/update 500 Internal Server Error in 16.679208ms

Sorry I can't be of more help in debugging (or even fixing this), but I've only just started on my journey learning Go, and I know very little about the architecture of Gitea - this is what I've been able to glean in about 10 minutes of poking through the code.

My suggestions going forward:

• Gitea should post a "minimum git version" (not sure what that would be, but I suppose it would involve greping for all of the places that git is used and making sure that all of the needed options and output are available - this might be a great automated testing project even, for when Gitea is modified or new versions of git are released)
• Something isn't right with error handling/notification (or else my logger is somehow set up wrong?) because it should have told me that the git command had failed, which will make diagnosing issues like this easier for everyone in the future

[lafriks]

I think this should be fixed by #4059

[perpetual-hydrofoil]

Seems to still be a problem:

Gitea version b1ad573 built with: bindata, sqlite

I haven't run the sqlite changes yet - instead, I just upgraded gitea. When I ran into this with a repo again, I just deleted the empty repo, recreated, and re-pushed. Still seeing the HOWTO.

[ronnicek]

And filesystem from which gitea is running doesnt have noexec option?

[confusedsushi]

I also observing this issue.
Tested with 1.5.1 and fb3954f.
Host is a Windows Server 2012 R2 on NTFS. Database is sqlite. Updating the Database manually is resolving this.

[lafriks]

Check gitea.log for errors

[confusedsushi]

2018/10/09 12:52:40 [I] Log Mode: File(Trace)
2018/10/09 12:52:40 [I] XORM Log Mode: File(Trace)
2018/10/09 12:52:40 [I] Cache Service Enabled
2018/10/09 12:52:40 [I] Session Service Enabled
2018/10/09 12:52:40 [W] Register Mail Service: Mail Service is not enabled
2018/10/09 12:52:40 [W] Notify Mail Service: Mail Service is not enabled
2018/10/09 12:52:40 [I] Git Version: 2.19.1
2018/10/09 12:52:40 [T] Doing: CheckRepoStats
2018/10/09 12:52:40 [T] Doing: ArchiveCleanup
2018/10/09 12:52:40 [T] Doing: DeletedBranchesCleanup
2018/10/09 12:52:49 [I] SQLite3 Supported
2018/10/09 12:52:49 [I] Run Mode: Production
2018/10/09 12:52:50 [I] Listen: https://0.0.0.0:22002
2018/10/09 12:52:50 [I] LFS server enabled
2018/10/09 12:52:50 [I] Redirecting: 0.0.0.0:8002 to https://server:22002
2018/10/09 12:53:30 [D] Session ID: 0fbfdd502a893efa
2018/10/09 12:53:30 [D] CSRF Token: vAuYZ5-Zyye8-G9C_oUzVDUr3ZY6MTUzOTA4MjQxMDk5NzY5OTkwMA==
2018/10/09 12:53:31 [D] Session ID: 0fbfdd502a893efa
2018/10/09 12:53:31 [D] CSRF Token: vAuYZ5-Zyye8-G9C_oUzVDUr3ZY6MTUzOTA4MjQxMDk5NzY5OTkwMA==
2018/10/09 12:53:31 [D] Session ID: 0fbfdd502a893efa
2018/10/09 12:53:31 [D] CSRF Token: zaZ_yXyrcZYdnC8NEcg_iRBQKgQ6MTUzOTA4MjQxMTEwMzI2MzkwMA==
2018/10/09 12:53:31 [D] Template: repo/bare

pushed something here

2018/10/09 12:53:37 [D] Session ID: e82c4b6854058b77
2018/10/09 12:53:37 [D] CSRF Token: IFbaafmStsNDxiU5AbqgBVqsgxs6MTUzOTA4MjQxNzY1ODE0MTQwMA==
2018/10/09 12:53:38 [D] Session ID: e38f1853fe91a3bb
2018/10/09 12:53:38 [D] CSRF Token: UNV87_BuTzMeUDHqICipRw8HkyE6MTUzOTA4MjQxODExMDMwNDkwMA==
2018/10/09 12:53:39 [D] Session ID: 78166083d8fcef78
2018/10/09 12:53:39 [D] CSRF Token: Cm-51_Uaix_IVIo5hLWxik7KBJQ6MTUzOTA4MjQxOTA0NTQ5MTcwMA==
2018/10/09 12:53:44 [D] Session ID: 0fbfdd502a893efa
2018/10/09 12:53:44 [D] CSRF Token: zaZ_yXyrcZYdnC8NEcg_iRBQKgQ6MTUzOTA4MjQxMTEwMzI2MzkwMA==
2018/10/09 12:53:44 [D] Template: repo/bare

[pcopissa]

I have the same symptoms (nothing shows up in the repository home page, even after two pushes).
I can use the git client (push, clone etc..) and the files are indeed stored (and updated) in the objects directory. But the web UI shows no commit.

Server side

• CentOS 7.5.1804 VM (with SELinux enabled, if that matters).
• PostgreSQL 10.5.
• git 2.18.
• Gitea 1.5.1
• Field is_bare for the repository is already reported as "true"
• repository is in /var/lib/git//, gitea are as per default install (/var/lib/gitea) on a plain CentOS install so (AFAICT) there is no noexec bit there.

Client side

• Windows 10 (64 bits)
• GitExtensions 2.50.02 (32 bits ?) + MSYS2 64 & 32 bits
• plink 0.67 (32 bits ?)
• git 2.15.1 64 bits

[confusedsushi]

It seems that the hook which should update the database is not executed always. While evaluating, I ran multiple times into this issue, but somehow the push on the production system did not had this issue.

[pcopissa]

I installed yesterday's version (gitea 1.5.2). For a good measure, I disabled SELinux (setenforce 0) and set the log to Trace then restarted gitea service (systemctl restart gitea).
Nada. The web UI remains unchanged.
The log does not move when making a push (dunno if this is expected though ?).
Is there a simple way to test that the hooks are indeed called (simpler than inserting some extra lines to trace entry and exit in a custom log file) ?

[pcopissa]

I further fiddled with gitea 1.5.2:

• De-installed it (stopped gitea service, removed all subfolders of /var/lib/git, removed second level files and subfolders of /var/lib/gitea, removed /etc/gitea/app.ini, dropped database gitea and recreated it)
• Installed (systemctl start gitea) and navigated to the home page, which asks for config stuff.
• Registered the first user (which must not be named "admin" by the way)
• Logged in with that user, tried to create a repository. Unexpectedly got the login page (as above). Occurred to me this may well be a cached cookie issue (I did not log out in the previous attempts either...).
• Closed my browser (Firefox), which due to my privacy settings causes all cookies to be cancelled.
• Logged in again with that user, tried to create a repository and this time I got the expected page. This time, I opted to have a default initial content (readme.md etc...) which I did not do in the previous attempts (in other words, I had until now left the checkbox in its default state unchecked).
• From Windows Client (GitExtension) cloned the repository, added a file, made add + commit + push.
• From the web UI I can now see the new file !

So the issue of the frozen repository page seems correlated to the fact that the offending repository started completely empty. When pre-populated with the readme.md etc.. it did not happen.
I now have to figure out how to close an issue via commit / push.

[perpetual-hydrofoil]

@pcopissa This is what I see as well. You have to create a README/.gitignore inside the UI to get it working; you can't just push to the empty repo and then expect the UI to pick up on your changes. :(

(and, yes, @ronnicek it's the root filesystem) btw, @lafriks this should probably be re-opened?

[lunny]

Still cannot reproduce on MacOS

[pcopissa]

For the record, I enabled SELinux again (setenforce 1) and modifications to the files are shown in the web UI.

[perpetual-hydrofoil]

@pcopissa this issue only appears to impact brand new repos (including on non-SELinux distros). Do you still see this after:

1. creating a new repo with no files (no readme, no .gitignore)
2. pushing to that repo

If you are still having the issue, your initial push will not show up in the web UI (it'll look as if the git repo is empty)

[pcopissa]

@jamiesonbecker I confirm I just ran step 1 and 2 above and the web UI shows no file.
Interestingly, GitExtension understood that situation and proposed to create a .gitignore file for me (which I declined).

• I created another repository, but this time accepted the creation of .gitignore in the working copy, then add + commit + push. Web UI remains unresponsive (as before)
• Added + committed + pushed README.md from the client. Web UI remains unresponsive as before. And I should add, the content of that pushed README.md is not shown in the home page.

[perpetual-hydrofoil]

@pcopissa hmm, maybe creating .gitignore isn't enough... might be that README.md has to be created in the UI at initial creation..

[pcopissa]

This issue is particularly annoying because it is the direct result of leaving the web UI defaults unchanged when creating a new repository. This is a perfect way of discouraging people evaluating the software to continue.
I therefore suggest (as a mitigation, not as a fix) to change the default value of the checkbox "Initialize Repository (Adds .gitignore, License and Readme)" to be checked. That way, newbies like me will hopefully be less likely to get bitten by that bug...

[perpetual-hydrofoil]

Agreed - of course, adding a file seems to make it more difficult to push an existing repo with a git history of its own.

[pcopissa]

I now have to deal with something that looks like issue #3848...

[nandoflorestan]

@lafriks

I think you should reopen this issue because it certainly isn't gone...

I am having the problem with gitea 1.9.1 on CentOS, git 2.21.0, filesystem is NOT noexec.

Please advise...

[MaciejKucia]

Reproducible on Gitea Version: 1.9.3

[lunny]

Please fire another issue and give more detail there.

[ghost]

Have you ensured that your SSD partition is not flagged "noexec", as I documented above? Gitea relies on executable hooks in the git repositories, if the partition does not permit these to execute then the operations will fail within the shelled-out "git" command in a way that doesn't give great tracebacks to Gitea. This was the cause of my problem. -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com 1 Oct 2020, 08:25 by [email protected]:

…

Same for me: Gitea version: v1.12.4 Git version: 2.24.3 Operating system: Alpine (Docker image) Database: SQLite I'm running the docker image below on a raspberry pi 3 and the /data directory is mounted on a USB external ssd. > https://hub.docker.com/r/kunde21/gitea-arm — You are receiving this because you were mentioned. Reply to this email directly, > view it on GitHub <#2898 (comment)>> , or > unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI5DXJ64LYANKD4TBVKAQTSIQVHZANCNFSM4EDLMFSA>> .

[nicos68]

Have you ensured that your SSD partition is not flagged "noexec", as I documented above? Gitea relies on executable hooks in the git repositories, if the partition does not permit these to execute then the operations will fail within the shelled-out "git" command in a way that doesn't give great tracebacks to Gitea. This was the cause of my problem. -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com 1 Oct 2020, 08:25 by [email protected]:
…
Same for me: Gitea version: v1.12.4 Git version: 2.24.3 Operating system: Alpine (Docker image) Database: SQLite I'm running the docker image below on a raspberry pi 3 and the /data directory is mounted on a USB external ssd. > https://hub.docker.com/r/kunde21/gitea-arm — You are receiving this because you were mentioned. Reply to this email directly, > view it on GitHub <#2898 (comment)>> , or > unsubscribe https://github.com/notifications/unsubscribe-auth/AAI5DXJ64LYANKD4TBVKAQTSIQVHZANCNFSM4EDLMFSA> .

Well, I first tested just after changing my fstab file with no luck, but I just made another test after restarting the pi and now it works, so I guess you can forget my comment, sorry.