github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-07-16 13:20:06 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

Nothing happens when using the initial configuration page #10611

New Issue
Closed
opened 2025-11-02 09:12:34 -06:00 by GiteaMirror · 19 comments
GiteaMirror commented 2025-11-02 09:12:34 -06:00
Owner
Copy Link

Originally created by @KuenzelIT on GitHub (Apr 7, 2023).

Description

After clicking on "Install Gitea" in the initial configuration the page is loading for a few seconds and then nothing happens and the initial configuration page is still shown, even after visiting the gitea url again. I did not change any options.

Gitea Version

1.19.0

Can you reproduce the bug on the Gitea demo site?

No

Log Gist

https://gist.github.com/KuenzelIT/20f406fc2edf5378d1d1dd4ad9e88cbc

Screenshots

No response

Git Version

No response

Operating System

Synology DSM

How are you running Gitea?

Docker Compose on a Synology:

version: "3"

networks:
gitea:
external: false

services:
server:
image: gitea/gitea:1.19.0
container_name: gitea
environment:
- USER_UID=1026
- USER_GID=100
- GITEA__database__DB_TYPE=mysql
- GITEA__database__HOST=db:3306
- GITEA__database__NAME=gitea
- GITEA__database__USER=gitea
- GITEA__database__PASSWD=gitea
restart: always
networks:
- gitea
volumes:
- ./gitea:/data
- /etc/TZ:/etc/timezone:ro
- /etc/localtime:/etc/localtime:ro
ports:
- "3000:3000"
- "222:22"
depends_on:
- db

db:
image: mysql:8
restart: always
environment:
- MYSQL_ROOT_PASSWORD=gitea
- MYSQL_USER=gitea
- MYSQL_PASSWORD=gitea
- MYSQL_DATABASE=gitea
networks:
- gitea
volumes:
- ./mysql:/var/lib/mysql

Database

MySQL

Originally created by @KuenzelIT on GitHub (Apr 7, 2023). ### Description After clicking on "Install Gitea" in the initial configuration the page is loading for a few seconds and then nothing happens and the initial configuration page is still shown, even after visiting the gitea url again. I did not change any options. ### Gitea Version 1.19.0 ### Can you reproduce the bug on the Gitea demo site? No ### Log Gist https://gist.github.com/KuenzelIT/20f406fc2edf5378d1d1dd4ad9e88cbc ### Screenshots _No response_ ### Git Version _No response_ ### Operating System Synology DSM ### How are you running Gitea? Docker Compose on a Synology: version: "3" networks: gitea: external: false services: server: image: gitea/gitea:1.19.0 container_name: gitea environment: - USER_UID=1026 - USER_GID=100 - GITEA__database__DB_TYPE=mysql - GITEA__database__HOST=db:3306 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=gitea restart: always networks: - gitea volumes: - ./gitea:/data - /etc/TZ:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - "3000:3000" - "222:22" depends_on: - db db: image: mysql:8 restart: always environment: - MYSQL_ROOT_PASSWORD=gitea - MYSQL_USER=gitea - MYSQL_PASSWORD=gitea - MYSQL_DATABASE=gitea networks: - gitea volumes: - ./mysql:/var/lib/mysql ### Database MySQL
GiteaMirror added the issue/needs-feedbacktype/bug labels 2025-11-02 09:12:34 -06:00
GiteaMirror commented 2025-11-02 09:12:35 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Apr 8, 2023):

I have tested your docker-compose.yaml :

  1. Copy it into my docker-compose.yaml
  2. docker-compose up
  3. Visit localhost:3000
  4. Click Install

After a few seconds, I can see the login UI.

The log looks like this:

gitea          | 2023/04/08 18:15:21 ...c/net/http/server.go:2122:ServeHTTP() [I] [64313eb9] PING DATABASE mysql
gitea          | 2023/04/08 18:15:24 ...eb/routing/logger.go:67:func1() [W] [64313eab-5] router: slow      POST / for 172.28.0.1:55794, elapsed 3456.8ms @ install/install.go:236(install.SubmitInstall)
gitea          | 2023/04/08 18:15:31 ...s/install/install.go:515:SubmitInstall() [I] Save settings to custom config file /data/gitea/conf/app.ini
gitea          | 2023/04/08 18:15:31 routers/common/db.go:21:InitDBEngine() [I] Beginning ORM engine initialization.
gitea          | 2023/04/08 18:15:31 routers/common/db.go:28:InitDBEngine() [I] ORM engine initialization attempt #1/10...

From your log , I can see:


######### the first try

gitea     | 2023/04/07 18:39:39 ...c/net/http/server.go:2122:ServeHTTP() [I] [6430474b] PING DATABASE mysql
gitea     | 2023/04/07 18:39:43 ...eb/routing/logger.go:67:func1() [W] [64304622] router: slow      POST / for 192.168.16.1:54058, elapsed 3746.2ms @ install/install.go:236(install.SubmitInstall)
======= why there is no detailed log here
gitea     | 2023/04/07 18:39:55 ...eb/routing/logger.go:98:func1() [I] router: completed POST / for 192.168.16.1:54058, 200 OK in 16550.8ms @ install/install.go:236(install.SubmitInstall)
gitea     | 2023/04/07 18:45:41 ...eb/routing/logger.go:98:func1() [I] [643048b5] router: completed GET / for 192.168.16.1:54402, 200 OK in 93.3ms @ install/install.go:90(install.Install)

...

######### the second try , the database part has been installed, but the app.ini doesn't get INSTALL_LOCK=true

gitea     | 2023/04/07 18:47:15 ...s/install/install.go:229:checkDatabase() [I] [64304913] Gitea will be installed in a database with: hasPostInstallationUser=false, dbMigrationVersion=244
gitea     | 2023/04/07 18:47:15 ...c/net/http/server.go:2122:ServeHTTP() [I] [64304913] PING DATABASE mysql
gitea     | 2023/04/07 18:47:16 modules/web/wrap.go:40:func1() [W] [64304913] Table system_setting Column version db default is , struct default is 1
gitea     | 2023/04/07 18:47:19 ...eb/routing/logger.go:67:func1() [W] [64304622] router: slow      POST / for 192.168.16.1:54402, elapsed 3413.2ms @ install/install.go:236(install.SubmitInstall)
======= why there is no detailed log here
gitea     | 2023/04/07 18:47:34 ...eb/routing/logger.go:98:func1() [I] [64304913] router: completed POST / for 192.168.16.1:54402, 200 OK in 18438.7ms @ install/install.go:236(install.SubmitInstall)

Just FYI, I have no more idea about this issue at the moment.

@wxiaoguang commented on GitHub (Apr 8, 2023): I have tested your docker-compose.yaml : 1. Copy it into my docker-compose.yaml 2. `docker-compose up` 3. Visit `localhost:3000` 4. Click `Install` After a few seconds, I can see the login UI. The log looks like this: ``` gitea | 2023/04/08 18:15:21 ...c/net/http/server.go:2122:ServeHTTP() [I] [64313eb9] PING DATABASE mysql gitea | 2023/04/08 18:15:24 ...eb/routing/logger.go:67:func1() [W] [64313eab-5] router: slow POST / for 172.28.0.1:55794, elapsed 3456.8ms @ install/install.go:236(install.SubmitInstall) gitea | 2023/04/08 18:15:31 ...s/install/install.go:515:SubmitInstall() [I] Save settings to custom config file /data/gitea/conf/app.ini gitea | 2023/04/08 18:15:31 routers/common/db.go:21:InitDBEngine() [I] Beginning ORM engine initialization. gitea | 2023/04/08 18:15:31 routers/common/db.go:28:InitDBEngine() [I] ORM engine initialization attempt #1/10... ``` From your log , I can see: ``` ######### the first try gitea | 2023/04/07 18:39:39 ...c/net/http/server.go:2122:ServeHTTP() [I] [6430474b] PING DATABASE mysql gitea | 2023/04/07 18:39:43 ...eb/routing/logger.go:67:func1() [W] [64304622] router: slow POST / for 192.168.16.1:54058, elapsed 3746.2ms @ install/install.go:236(install.SubmitInstall) ======= why there is no detailed log here gitea | 2023/04/07 18:39:55 ...eb/routing/logger.go:98:func1() [I] router: completed POST / for 192.168.16.1:54058, 200 OK in 16550.8ms @ install/install.go:236(install.SubmitInstall) gitea | 2023/04/07 18:45:41 ...eb/routing/logger.go:98:func1() [I] [643048b5] router: completed GET / for 192.168.16.1:54402, 200 OK in 93.3ms @ install/install.go:90(install.Install) ... ######### the second try , the database part has been installed, but the app.ini doesn't get INSTALL_LOCK=true gitea | 2023/04/07 18:47:15 ...s/install/install.go:229:checkDatabase() [I] [64304913] Gitea will be installed in a database with: hasPostInstallationUser=false, dbMigrationVersion=244 gitea | 2023/04/07 18:47:15 ...c/net/http/server.go:2122:ServeHTTP() [I] [64304913] PING DATABASE mysql gitea | 2023/04/07 18:47:16 modules/web/wrap.go:40:func1() [W] [64304913] Table system_setting Column version db default is , struct default is 1 gitea | 2023/04/07 18:47:19 ...eb/routing/logger.go:67:func1() [W] [64304622] router: slow POST / for 192.168.16.1:54402, elapsed 3413.2ms @ install/install.go:236(install.SubmitInstall) ======= why there is no detailed log here gitea | 2023/04/07 18:47:34 ...eb/routing/logger.go:98:func1() [I] [64304913] router: completed POST / for 192.168.16.1:54402, 200 OK in 18438.7ms @ install/install.go:236(install.SubmitInstall) ``` Just FYI, I have no more idea about this issue at the moment.
GiteaMirror commented 2025-11-02 09:12:36 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Apr 8, 2023):

Does your cookie/domain/browser work correctly? (Just a guess, I am not sure)

Maybe there is an error message, but the wrong cookie setting may cause the error message wouldn't be displayed, so you didn't get the error feedback?

@wxiaoguang commented on GitHub (Apr 8, 2023): Does your cookie/domain/browser work correctly? (Just a guess, I am not sure) Maybe there is an error message, but the wrong cookie setting may cause the error message wouldn't be displayed, so you didn't get the error feedback?
GiteaMirror commented 2025-11-02 09:12:36 -06:00
Author
Owner
Copy Link

@KuenzelIT commented on GitHub (Apr 9, 2023):

Thank you for testing!

Your logs gave me the idea to see if the app.ini was created and it was. I then tried settting the DOMAIN and SSH_DOMAIN from localhost to my servers domain name and see if anything changes. But the result was the same.

I also tried with INSTALL_LOCK = true to see any changes and the ORM tried to initialize, but after waiting for the mysql server, it didn't try again, although there were some attempts left.

I also tried with a fresh browser. The behaviour was the same.

As the logs say, the installer is very slow. Takes my machine more than 60 seconds to finish the POST request. May be my machine, but seems a little odd (in your case 10 seconds).

I have no idea what else to try right now. :)

@KuenzelIT commented on GitHub (Apr 9, 2023): Thank you for testing! Your logs gave me the idea to see if the app.ini was created and it was. I then tried settting the DOMAIN and SSH_DOMAIN from localhost to my servers domain name and see if anything changes. But the result was the same. I also tried with INSTALL_LOCK = true to see any changes and the ORM tried to initialize, but after waiting for the mysql server, it didn't try again, although there were some attempts left. I also tried with a fresh browser. The behaviour was the same. As the logs say, the installer is very slow. Takes my machine more than 60 seconds to finish the POST request. May be my machine, but seems a little odd (in your case 10 seconds). I have no idea what else to try right now. :)
GiteaMirror commented 2025-11-02 09:12:36 -06:00
Author
Owner
Copy Link

@wxiaoguang commented on GitHub (Apr 10, 2023):

As the logs say, the installer is very slow. Takes my machine more than 60 seconds to finish the POST request. May be my machine, but seems a little odd (in your case 10 seconds).

Hmm ... no idea either. Could the "slow" be the problem? What's your environment (hardware) & limitation? Is there enough CPU and memory resrouce?

@wxiaoguang commented on GitHub (Apr 10, 2023): > As the logs say, the installer is very slow. Takes my machine more than 60 seconds to finish the POST request. May be my machine, but seems a little odd (in your case 10 seconds). Hmm ... no idea either. Could the "slow" be the problem? What's your environment (hardware) & limitation? Is there enough CPU and memory resrouce?
GiteaMirror commented 2025-11-02 09:12:36 -06:00
Author
Owner
Copy Link

@KuenzelIT commented on GitHub (Apr 10, 2023):

I'm using a Synology DS920+. The performance is ok and I'm running some other docker containers without a problem. I thought Gitea is lightweight and should work. :)

I will monitor the CPU and memory the next time I try the install. But since the logs say that the POST request completed, I assume that this is not the problem.

Thanks again for your help!

@KuenzelIT commented on GitHub (Apr 10, 2023): I'm using a Synology DS920+. The performance is ok and I'm running some other docker containers without a problem. I thought Gitea is lightweight and should work. :) I will monitor the CPU and memory the next time I try the install. But since the logs say that the POST request completed, I assume that this is not the problem. Thanks again for your help!
GiteaMirror commented 2025-11-02 09:12:36 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (May 9, 2023):

Looks like it's normal from the provided logs.

@lunny commented on GitHub (May 9, 2023): Looks like it's normal from the provided logs.
GiteaMirror commented 2025-11-02 09:12:37 -06:00
Author
Owner
Copy Link

@nbgibson commented on GitHub (Jul 31, 2023):

@KuenzelIT Out of curiosity, are you running the docker container on a volume that is using btrfs? I'm encountering something similar in my install as well. However, I'm using a dedicated MariaDB instance running on the Syn box by way of their package center. The install is progressing as I can see it periodically making new tables in my DB, but it is taking its sweet time. I did a bit of digging around and it seems that btrfs and the data checksum checking of files in those shares may be the root of the problem here.

See:

I have yet to find the referenced Synology documentation on the matter* but I could see where the checksum checking could play a great deal into the performance overhead we're seeing here. I'm going to let things churn overnight on my end and try and set aside some time to see if the issue comes up on a MariaDB instance running on a different host.

  • It can be found here

To ensure service quality, we recommend not enabling data checksum when the shared folder will be used for the following services:
Hosting databases or virtual machines
Storing video recordings of Surveillance Station
Running services that require a small and random write pattern

@nbgibson commented on GitHub (Jul 31, 2023): @KuenzelIT Out of curiosity, are you running the docker container on a volume that is using btrfs? I'm encountering something similar in my install as well. However, I'm using a dedicated MariaDB instance running on the Syn box by way of their package center. The install *is* progressing as I can see it periodically making new tables in my DB, but it is taking its sweet time. I did a bit of digging around and it seems that btrfs and the data checksum checking of files in those shares may be the root of the problem here. See: - https://www.reddit.com/r/synology/comments/s9f3cg/mariadb_on_btrfs_is_slow_best_options/ - https://www.reddit.com/r/synology/comments/ry6nrk/til_dont_put_your_docker_confs_into_the_default/ ~~I have yet to find the referenced Synology documentation on the matter~~* but I could see where the checksum checking could play a great deal into the performance overhead we're seeing here. I'm going to let things churn overnight on my end and try and set aside some time to see if the issue comes up on a MariaDB instance running on a different host. * It can be found [here](https://kb.synology.com/en-ca/DSM/help/DSM/AdminCenter/file_share_create?version=6#:~:text=To%20ensure%20service,or%20virtual%20machines) *To ensure service quality, we recommend not enabling data checksum when the shared folder will be used for the following services: **Hosting databases** or virtual machines Storing video recordings of Surveillance Station **Running services that require a small and random write pattern***
GiteaMirror commented 2025-11-02 09:12:37 -06:00
Author
Owner
Copy Link

@KuenzelIT commented on GitHub (Dec 7, 2023):

Thanks for the idea. Unfortunately I'm not using btrfs. I also haven't tried to install gitea in a while, maybe I'll try again in a few days.

@KuenzelIT commented on GitHub (Dec 7, 2023): Thanks for the idea. Unfortunately I'm not using btrfs. I also haven't tried to install gitea in a while, maybe I'll try again in a few days.
GiteaMirror commented 2025-11-02 09:12:37 -06:00
Author
Owner
Copy Link

@thannerfabian commented on GitHub (Mar 4, 2024):

@KuenzelIT I am currently facing the same issues on a Synology DS224+. I am also running other docker containers without any problems. RAM and CPU load are both under 10% and I am not using btrfs as well.

The difference in my environment is, that I use an already installed MySQL instance and no docker container for it. And I use the latest version of gitea not 1.19.0 (didn´t check if the latest is 1.19.0).

Did you find any solution?

@thannerfabian commented on GitHub (Mar 4, 2024): @KuenzelIT I am currently facing the same issues on a Synology DS224+. I am also running other docker containers without any problems. RAM and CPU load are both under 10% and I am not using btrfs as well. The difference in my environment is, that I use an already installed MySQL instance and no docker container for it. And I use the latest version of gitea not 1.19.0 (didn´t check if the latest is 1.19.0). Did you find any solution?
GiteaMirror commented 2025-11-02 09:12:38 -06:00
Author
Owner
Copy Link

@KuenzelIT commented on GitHub (Mar 5, 2024):

I did not find a solution and dropped trying it for now, sorry :(

@KuenzelIT commented on GitHub (Mar 5, 2024): I did not find a solution and dropped trying it for now, sorry :(
GiteaMirror commented 2025-11-02 09:12:38 -06:00
Author
Owner
Copy Link

@thannerfabian commented on GitHub (Mar 6, 2024):

I am not sure how I got it working, but I did the installation on my Mac. After loading for a few minutes, I tried to open the webpage on one of my servers. In this moment, the installation was done and I got forwarded to homepage of Gitea. I dn´t know if it was luck or if this is the solution.

@thannerfabian commented on GitHub (Mar 6, 2024): I am not sure how I got it working, but I did the installation on my Mac. After loading for a few minutes, I tried to open the webpage on one of my servers. In this moment, the installation was done and I got forwarded to homepage of Gitea. I dn´t know if it was luck or if this is the solution.
GiteaMirror commented 2025-11-02 09:12:38 -06:00
Author
Owner
Copy Link

@lovehumans commented on GitHub (Oct 26, 2024):

I'm having the same problem, no btrfs, DS720+, using forgejo:9-rootless with a pg:14 in a container.
I don't see any CPU usage from the forgejo container and it just doesn't do anything after clicking "Install".
I don't see it writing an ini file in the volume either.
Other docker projects run fine.

@lovehumans commented on GitHub (Oct 26, 2024): I'm having the same problem, no btrfs, DS720+, using forgejo:9-rootless with a pg:14 in a container. I don't see any CPU usage from the forgejo container and it just doesn't do anything after clicking "Install". I don't see it writing an ini file in the volume either. Other docker projects run fine.
GiteaMirror commented 2025-11-02 09:12:39 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Oct 26, 2024):

Maybe you need to check whether there is permission to write the app.ini to the mounted data directory.

@lunny commented on GitHub (Oct 26, 2024): Maybe you need to check whether there is permission to write the app.ini to the mounted data directory.
GiteaMirror commented 2025-11-02 09:12:39 -06:00
Author
Owner
Copy Link

@lovehumans commented on GitHub (Oct 27, 2024):

That was a hurdle I've crossed since posting, but it's still not working.
I had to chown the folders to user id 1000, because that's the ID of the GIT user inside the docker container, regardless of what I set the environment variables for USER_ID, within the docker compose yaml.

Now after doing this, if I select SQLite3, it does create an app.ini, but when I pick the Postgres DB, it does not.
(When picking SQLite3, the install doesn't work, since the DB Type is set to Postgres in the yaml, but that's beside the point, I'd prefer a Postgres install anyway)

@lovehumans commented on GitHub (Oct 27, 2024): That was a hurdle I've crossed since posting, but it's still not working. I had to chown the folders to user id 1000, because that's the ID of the GIT user inside the docker container, regardless of what I set the environment variables for USER_ID, within the docker compose yaml. Now after doing this, if I select SQLite3, it does create an app.ini, but when I pick the Postgres DB, it does not. (When picking SQLite3, the install doesn't work, since the DB Type is set to Postgres in the yaml, but that's beside the point, I'd prefer a Postgres install anyway)
GiteaMirror commented 2025-11-02 09:12:39 -06:00
Author
Owner
Copy Link

@lovehumans commented on GitHub (Oct 27, 2024):

I gave up on Postgres DB and have it running on SQLite now.
So a major hint for anyone having issues: even though the error messages might not suggest something is up with the DB, it might be.

@lovehumans commented on GitHub (Oct 27, 2024): I gave up on Postgres DB and have it running on SQLite now. So a major hint for anyone having issues: even though the error messages might not suggest something is up with the DB, it might be.
GiteaMirror commented 2025-11-02 09:12:39 -06:00
Author
Owner
Copy Link

@aleleba commented on GitHub (Dec 27, 2024):

It is happening to me also I am using a DS923+

@aleleba commented on GitHub (Dec 27, 2024): It is happening to me also I am using a DS923+
GiteaMirror commented 2025-11-02 09:12:40 -06:00
Author
Owner
Copy Link

@dirkmacke commented on GitHub (Apr 21, 2025):

I had the same issues on my DS1221+. I used the docker compose file from here. Found out, that the db dierctory had wrong permissions after running the docker compose (only permissions were set for a non-existing user "999"). I could resolve the issue by giving the admin group on my Syno recursively full access to the db directory.

Would appreciate to get some feedback, if I potentially did something stupid by this and how the proper permissions for the db directories/the pg installation should look like...

@dirkmacke commented on GitHub (Apr 21, 2025): I had the same issues on my DS1221+. I used the docker compose file from [here](https://mariushosting.com/how-to-install-forgejo-on-your-synology-nas/). Found out, that the db dierctory had wrong permissions after running the docker compose (only permissions were set for a non-existing user "999"). I could resolve the issue by giving the admin group on my Syno recursively full access to the db directory. Would appreciate to get some feedback, if I potentially did something stupid by this and how the proper permissions for the db directories/the pg installation should look like...
GiteaMirror commented 2025-11-02 09:12:40 -06:00
Author
Owner
Copy Link

@GiteaBot commented on GitHub (Jul 30, 2025):

We close issues that need feedback from the author if there were no new comments for a month. 🍵

@GiteaBot commented on GitHub (Jul 30, 2025): We close issues that need feedback from the author if there were no new comments for a month. :tea:
GiteaMirror commented 2025-11-02 09:12:40 -06:00
Author
Owner
Copy Link

@Kellojo commented on GitHub (Sep 30, 2025):

Had the exact same issue. I was able to resolve it by sshing into my Synology nas and running 🚀:

sudo chown -R 1000:1000 ./gitea-db
@Kellojo commented on GitHub (Sep 30, 2025): Had the exact same issue. I was able to resolve it by sshing into my Synology nas and running 🚀: ```sh sudo chown -R 1000:1000 ./gitea-db ````
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
$20
$250
$50
$500
backport/done
💎 Bounty
docs-update-needed
good first issue
hacktoberfest
issue/bounty
issue/confirmed
issue/critical
issue/duplicate
issue/needs-feedback
issue/not-a-bug
issue/regression
issue/stale
issue/workaround
lgtm/need 2
modifies/api
modifies/translation
outdated/backport/v1.18
outdated/theme/markdown
outdated/theme/timetracker
performance/bigrepo
performance/cpu
performance/memory
performance/speed
pr/breaking
proposal/accepted
proposal/rejected
pr/wip
pull-request
Mirrored from GitHub Pull Request
 reviewed/wontfix
💰 Rewarded
skip-changelog
status/blocked
topic/accessibility
topic/api
topic/authentication
topic/build
topic/code-linting
topic/commit-signing
topic/content-rendering
topic/deployment
topic/distribution
topic/federation
topic/gitea-actions
topic/issues
topic/lfs
topic/mobile
topic/moderation
topic/packages
topic/pr
topic/projects
topic/repo
topic/repo-migration
topic/security
topic/theme
topic/ui
topic/ui-interaction
topic/ux
topic/webhooks
topic/wiki
type/bug
type/deprecation
type/docs
type/enhancement
type/feature
type/miscellaneous
type/proposal
type/question
type/refactoring
type/summary
type/testing
type/upstream
No Label issue/needs-feedback type/bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#10611
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?