When creating repo without init it shows still howto #1238

@ronnicek commented on GitHub (Nov 13, 2017):

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

@ronnicek commented on GitHub (Nov 13, 2017): Is there any way how I can debug it more from my side?

GiteaMirror commented

@lunny commented on GitHub (Nov 13, 2017):

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

@lunny commented on GitHub (Nov 13, 2017): Could you find the xorm.log to put it also on gist?

GiteaMirror commented

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

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.

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

GiteaMirror commented

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

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

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

GiteaMirror commented

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

repo.IsBare is only updated in once place, in CommitRepoAction: f2e20c81b6/models/action.go (L527)

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 1773e88643. Once again this is only called from one place: 9ddbbd9d5a/cmd/hook.go (L203) 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.

@smaeul commented on GitHub (Jan 5, 2018): `repo.IsBare` is only updated in once place, in `CommitRepoAction`: https://github.com/go-gitea/gitea/blob/f2e20c81b66e6a937ecdb686f8d1011371433365/models/action.go#L527 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 https://github.com/go-gitea/gitea/commit/1773e88643a2df7e7efbe86ec424409b45a4d576. Once again this is only called from one place: https://github.com/go-gitea/gitea/blob/9ddbbd9d5a67e430ccf942d28088c9b4c2bb991f/cmd/hook.go#L203 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.

GiteaMirror commented

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

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.

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

GiteaMirror commented

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

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?

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

GiteaMirror commented

@JohannesBauer97 commented on GitHub (Feb 2, 2018):

Same error

@JohannesBauer97 commented on GitHub (Feb 2, 2018): Same error

GiteaMirror commented

@abatkin commented on GitHub (Jun 3, 2018):

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 commented on GitHub (Jun 3, 2018): 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.

GiteaMirror commented

@abatkin commented on GitHub (Jun 4, 2018):

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

@abatkin commented on GitHub (Jun 4, 2018): 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

GiteaMirror commented

@lafriks commented on GitHub (Jun 4, 2018):

I think this should be fixed by #4059

@lafriks commented on GitHub (Jun 4, 2018): I think this should be fixed by #4059

GiteaMirror commented

@perpetual-hydrofoil commented on GitHub (Aug 18, 2018):

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.

@perpetual-hydrofoil commented on GitHub (Aug 18, 2018): 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.

GiteaMirror commented

@ronnicek commented on GitHub (Aug 18, 2018):

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

@ronnicek commented on GitHub (Aug 18, 2018): And filesystem from which gitea is running doesnt have noexec option?

GiteaMirror commented

@confusedsushi commented on GitHub (Oct 9, 2018):

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.

@confusedsushi commented on GitHub (Oct 9, 2018): 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.

GiteaMirror commented

@lafriks commented on GitHub (Oct 9, 2018):

Check gitea.log for errors

@lafriks commented on GitHub (Oct 9, 2018): Check gitea.log for errors

GiteaMirror commented

@confusedsushi commented on GitHub (Oct 9, 2018):

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

@confusedsushi commented on GitHub (Oct 9, 2018): ```log 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 ```log 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 ```

GiteaMirror commented

@pcopissa commented on GitHub (Oct 9, 2018):

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

@pcopissa commented on GitHub (Oct 9, 2018): 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/<user>/, 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

GiteaMirror commented

@confusedsushi commented on GitHub (Oct 9, 2018):

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.

@confusedsushi commented on GitHub (Oct 9, 2018): 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.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 10, 2018):

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 commented on GitHub (Oct 10, 2018): 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) ?

GiteaMirror commented

@pcopissa commented on GitHub (Oct 10, 2018):

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.

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

GiteaMirror commented

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018):

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

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018): @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?

GiteaMirror commented

@lunny commented on GitHub (Oct 10, 2018):

Still cannot reproduce on MacOS

@lunny commented on GitHub (Oct 10, 2018): Still cannot reproduce on MacOS

GiteaMirror commented

@pcopissa commented on GitHub (Oct 10, 2018):

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

@pcopissa commented on GitHub (Oct 10, 2018): For the record, I enabled SELinux again (`setenforce 1`) and modifications to the files are shown in the web UI.

GiteaMirror commented

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018):

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

creating a new repo with no files (no readme, no .gitignore)
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)

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018): @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)

GiteaMirror commented

@pcopissa commented on GitHub (Oct 10, 2018):

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

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

GiteaMirror commented

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018):

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

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018): @pcopissa hmm, maybe creating `.gitignore` isn't enough... might be that `README.md` has to be created in the UI at initial creation..

GiteaMirror commented

@pcopissa commented on GitHub (Oct 10, 2018):

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

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

GiteaMirror commented

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018):

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

@perpetual-hydrofoil commented on GitHub (Oct 10, 2018): Agreed - of course, adding a file seems to make it more difficult to push an *existing* repo with a git history of its own.

GiteaMirror commented

@pcopissa commented on GitHub (Oct 10, 2018):

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

@pcopissa commented on GitHub (Oct 10, 2018): I now have to deal with something that looks like issue #3848...

GiteaMirror commented

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

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

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

GiteaMirror commented

@MaciejKucia commented on GitHub (Sep 19, 2019):

Reproducible on Gitea Version: 1.9.3

@MaciejKucia commented on GitHub (Sep 19, 2019): Reproducible on Gitea Version: 1.9.3

GiteaMirror commented