github-starred/gitea
2
0
Fork 0
mirror of https://github.com/go-gitea/gitea.git synced 2026-03-19 14:42:41 -05:00
Code Issues 2.6k Packages Projects Releases 100 Wiki Activity

[Info] Update from 1.9 to 1.10.x raises [E] InitIssuesIndexer: create index, mkdir /usr/local/bin/data: permission denied #4519

New Issue
Closed
opened 2025-11-02 05:53:20 -06:00 by GiteaMirror · 10 comments
GiteaMirror commented 2025-11-02 05:53:20 -06:00
Owner
Copy Link

Originally created by @mbedded on GitHub (Dec 19, 2019).

  • Gitea version (or commit ref): 1.10.2
  • Git version: 2.11.0
  • Operating system: Raspbian GNU/Linux 9 (stretch)
  • 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:

Description

An update from Gitea 1.9 to several 1.10 versions causes

[E] InitIssuesIndexer: create index, mkdir /usr/local/bin/data: permission denied

so the instance cannot be started instantly again after the update.
My update was (roughly) the following:

systemctl stop gitea
mv gitea gitea.bak
wget -O gitea DOWNLOAD_URL_OF_GITEA
systemctl start gitea

Every time the service was unable to start gitea again. I got the same error message as written in #6398. I downloaded different versions of gitea (1.10, 1.10.1, 1.10.2) everyone had the same issue.

After some time I decided to download 1.10.2 and restart my raspberry (shutdown -r).
As I did this, the server came back online and runs without any issues. I am not sure why a replacement of the Gitea-executable may cause a [E] InitIssuesIndexer: create index, mkdir /usr/local/bin/data: permission denied issue because the configuration file with information like database, filepaths etc. was not changed.

After restart of the Raspberry everything was fine again. I am not sure if this issue is already known. I found nothing in the repository yet.

If you have a better title, please feel free to adjust it for clarification :)

Summary

After an update of gitea [E] InitIssuesIndexer: create index, mkdir /usr/local/bin/data: permission denied is written in the log and the gitea-service is unable to be started again. A restart of the device (shutdown -r) fixes this problem.

Originally created by @mbedded on GitHub (Dec 19, 2019). - Gitea version (or commit ref): 1.10.2 - Git version: 2.11.0 - Operating system: Raspbian GNU/Linux 9 (stretch) - Database (use `[x]`): - [ ] PostgreSQL - [x] MySQL - [ ] MSSQL - [ ] SQLite - Can you reproduce the bug at https://try.gitea.io: - [ ] Yes (provide example URL) - [ ] No - [x] Not relevant - Log gist: ## Description An update from Gitea 1.9 to several 1.10 versions causes ``` [E] InitIssuesIndexer: create index, mkdir /usr/local/bin/data: permission denied ``` so the instance cannot be started instantly again after the update. My update was (roughly) the following: ``` systemctl stop gitea mv gitea gitea.bak wget -O gitea DOWNLOAD_URL_OF_GITEA systemctl start gitea ``` Every time the service was unable to start gitea again. I got the same error message as written in #6398. I downloaded different versions of gitea (1.10, 1.10.1, 1.10.2) everyone had the same issue. After some time I decided to download 1.10.2 and restart my raspberry (`shutdown -r`). As I did this, the server came back online and runs without any issues. I am not sure why a replacement of the Gitea-executable may cause a `[E] InitIssuesIndexer: create index, mkdir /usr/local/bin/data: permission denied` issue because the configuration file with information like database, filepaths etc. was not changed. After restart of the Raspberry everything was fine again. I am not sure if this issue is already known. I found nothing in the repository yet. If you have a better title, please feel free to adjust it for clarification :) ## Summary After an update of gitea `[E] InitIssuesIndexer: create index, mkdir /usr/local/bin/data: permission denied` is written in the log and the gitea-service is unable to be started again. A restart of the device (shutdown -r) fixes this problem.
GiteaMirror added the type/question label 2025-11-02 05:53:20 -06:00
GiteaMirror commented 2025-11-02 05:53:21 -06:00
Author
Owner
Copy Link

@lunny commented on GitHub (Dec 19, 2019):

your gitea binary is placed /usr/local/bin, but your indexer data should not be /usr/local/bin/data. Could you paste your systemctl script?

@lunny commented on GitHub (Dec 19, 2019): your gitea binary is placed `/usr/local/bin`, but your indexer data should not be `/usr/local/bin/data`. Could you paste your systemctl script?
GiteaMirror commented 2025-11-02 05:53:21 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Dec 19, 2019):

and ls -la /usr/local/bin/data to see the rights

@6543 commented on GitHub (Dec 19, 2019): and `ls -la /usr/local/bin/data` to see the rights
GiteaMirror commented 2025-11-02 05:53:21 -06:00
Author
Owner
Copy Link

@mbedded commented on GitHub (Dec 20, 2019):

Thank you for your quick feedback. My data is stored in /home/pi/gitea.

ls -lah /home/pi
drwxr-xr-x  5 pi   pi   4.0K Dec 18 13:47 gitea
drwx------  2 pi   pi   4.0K Mar 15  2019 gitea-lfs
drwxr-xr-x  3 pi   pi   4.0K Nov  5  2018 gitea-repositories

ls -lah /home/pi/gitea
drwxr-xr-x  4 pi pi 4.0K Dec 18 13:29 custom
drwxr-xr-x  7 pi pi 4.0K Dec 19 13:18 data
-rwxr-xr-x  1 pi pi  69M Dec  5 20:21 gitea
-rwxr-xr-x  1 pi pi  83M Sep  7 20:21 gitea.bak
drwxr-xr-x  3 pi pi 4.0K Dec 20 00:00 log

I installed the system-script as described in https://docs.gitea.io/en-us/linux-service/.

# Location
#   /etc/systemd/system/gitea.service
# Docs: https://docs.gitea.io/en-us/linux-service/

[Unit]
Description=Gitea
After=syslog.target
After=network.target

[Service]
# Modify these two values ​​and uncomment them if you have
# repos with lots of files and get to HTTP error 500 because of that
###
# LimitMEMLOCK=infinity
# LimitNOFILE=65535
RestartSec=2s
Type=simple
User=pi
Group=pi
WorkingDirectory=/home/pi/gitea
ExecStart=/home/pi/gitea/gitea web -c /home/pi/gitea/custom/conf/app.ini
Restart=always
Environment=USER=pi HOME=/home/pi GITEA_WORK_DIR=/home/pi/gitea/

[Install]
WantedBy=multi-user.target

I have no path called /usr/local/bin/data. It's strange that I have a custom and Gitea.

ls -lahR /usr/local/bin/
/usr/local/bin/:
total 53M
drwxrwsr-x  3 root staff 4.0K Mar 20  2019 .
drwxrwsr-x 10 root staff 4.0K Apr 18  2018 ..
drwxr-sr-x  3 root staff 4.0K Mar 20  2019 custom
-rwxr-xr-x  1 root staff  53M Mar 14  2019 gitea

/usr/local/bin/custom:
total 12K
drwxr-sr-x 3 root staff 4.0K Mar 20  2019 .
drwxrwsr-x 3 root staff 4.0K Mar 20  2019 ..
drwxr-sr-x 2 root staff 4.0K Mar 20  2019 conf

/usr/local/bin/custom/conf:
total 12K
drwxr-sr-x 2 root staff 4.0K Mar 20  2019 .
drwxr-sr-x 3 root staff 4.0K Mar 20  2019 ..
-rw-r--r-- 1 root staff  135 Mar 20  2019 app.ini

Could these folders (in /usr/local/bin) be created by using gitea web? As I tried Gitea the first time I executed the binary by using gitea web to test it. After it worked very well I decided to install it by using a service.
Because I am not that good with the user management in Linux yet I decided to run gitea as "pi" user on my raspberry, because there is no other service running on that device.

@mbedded commented on GitHub (Dec 20, 2019): Thank you for your quick feedback. My data is stored in /home/pi/gitea. ``` ls -lah /home/pi drwxr-xr-x 5 pi pi 4.0K Dec 18 13:47 gitea drwx------ 2 pi pi 4.0K Mar 15 2019 gitea-lfs drwxr-xr-x 3 pi pi 4.0K Nov 5 2018 gitea-repositories ls -lah /home/pi/gitea drwxr-xr-x 4 pi pi 4.0K Dec 18 13:29 custom drwxr-xr-x 7 pi pi 4.0K Dec 19 13:18 data -rwxr-xr-x 1 pi pi 69M Dec 5 20:21 gitea -rwxr-xr-x 1 pi pi 83M Sep 7 20:21 gitea.bak drwxr-xr-x 3 pi pi 4.0K Dec 20 00:00 log ``` I installed the system-script as described in https://docs.gitea.io/en-us/linux-service/. ``` # Location # /etc/systemd/system/gitea.service # Docs: https://docs.gitea.io/en-us/linux-service/ [Unit] Description=Gitea After=syslog.target After=network.target [Service] # Modify these two values ​​and uncomment them if you have # repos with lots of files and get to HTTP error 500 because of that ### # LimitMEMLOCK=infinity # LimitNOFILE=65535 RestartSec=2s Type=simple User=pi Group=pi WorkingDirectory=/home/pi/gitea ExecStart=/home/pi/gitea/gitea web -c /home/pi/gitea/custom/conf/app.ini Restart=always Environment=USER=pi HOME=/home/pi GITEA_WORK_DIR=/home/pi/gitea/ [Install] WantedBy=multi-user.target ``` I have no path called `/usr/local/bin/data`. It's strange that I have a `custom` and `Gitea`. ``` ls -lahR /usr/local/bin/ /usr/local/bin/: total 53M drwxrwsr-x 3 root staff 4.0K Mar 20 2019 . drwxrwsr-x 10 root staff 4.0K Apr 18 2018 .. drwxr-sr-x 3 root staff 4.0K Mar 20 2019 custom -rwxr-xr-x 1 root staff 53M Mar 14 2019 gitea /usr/local/bin/custom: total 12K drwxr-sr-x 3 root staff 4.0K Mar 20 2019 . drwxrwsr-x 3 root staff 4.0K Mar 20 2019 .. drwxr-sr-x 2 root staff 4.0K Mar 20 2019 conf /usr/local/bin/custom/conf: total 12K drwxr-sr-x 2 root staff 4.0K Mar 20 2019 . drwxr-sr-x 3 root staff 4.0K Mar 20 2019 .. -rw-r--r-- 1 root staff 135 Mar 20 2019 app.ini ``` Could these folders (in /usr/local/bin) be created by using `gitea web`? As I tried Gitea the first time I executed the binary by using gitea web to test it. After it worked very well I decided to install it by using a service. Because I am not that good with the user management in Linux yet I decided to run gitea as "pi" user on my raspberry, because there is no other service running on that device.
GiteaMirror commented 2025-11-02 05:53:22 -06:00
Author
Owner
Copy Link

@6543 commented on GitHub (Dec 20, 2019):

first look: It looks like the config file patjs do not match

@6543 commented on GitHub (Dec 20, 2019): first look: It looks like the config file patjs do not match
GiteaMirror commented 2025-11-02 05:53:22 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 20, 2019):

Yet again the non-standard paths problem strikes again.

Gitea does not obey the FHS. It expects to be run at the base of its configuration and data directories.

Sticking it in /usr/local/bin and expecting it to work like a FHS compliant program causes no end of trouble.

We should change our documentation to recommend using the FHS compliant wrapper script or rebuilding with the FHS compliant options.

I also genuinely think we should also offer two builds one with the current directory structure and one which complies with the FHS.

In this case I suspect that this problem is due to restarting Gitea without the appropriate environment for whatever reason. The reason that on restart of the pi it works is that the systemd unit file is then run properly and Gitea was started with the correct environment.

If you want Gitea to behave like an FHS compliant program use the wrapper or recompile. Placing it directly in /usr/local/bin is recipe for gotchas.

@zeripath commented on GitHub (Dec 20, 2019): Yet again the non-standard paths problem strikes again. Gitea does not obey the FHS. It expects to be run at the base of its configuration and data directories. Sticking it in /usr/local/bin and expecting it to work like a FHS compliant program causes no end of trouble. We should change our documentation to recommend using the FHS compliant wrapper script or rebuilding with the FHS compliant options. I also genuinely think we should also offer two builds one with the current directory structure and one which complies with the FHS. In this case I suspect that this problem is due to restarting Gitea without the appropriate environment for whatever reason. The reason that on restart of the pi it works is that the systemd unit file is then run properly and Gitea was started with the correct environment. If you want Gitea to behave like an FHS compliant program use the wrapper or recompile. Placing it directly in /usr/local/bin is recipe for gotchas.
GiteaMirror commented 2025-11-02 05:53:22 -06:00
Author
Owner
Copy Link

@mbedded commented on GitHub (Dec 21, 2019):

I am sorry but I didn't understood that in complete :/

In my service I have the following line

ExecStart=/home/pi/gitea/gitea web -c /home/pi/gitea/custom/conf/app.ini

There is a path to my gitea executable with -c giving the configuration file. What confuses me is the fact that stop service and start service are working after I restarted my device. But downloading the file, adding chmod +x and start the service again should be working.
I am not entirely sure why this causes an issue.
The config file uses absolute paths to avoid issues with relative paths like missing data or data stored in strange places.

I am not working with Linux that much yet (only since 6-7 months) so I assumed (coming from a Windows world) there should be no issues when I replace an executable with another one.

We should change our documentation to recommend using the FHS compliant wrapper script or rebuilding with the FHS compliant options.

If you see some better ways to install or use gitea feel free to adjust the documentation if this fits better than a bugfix within the code. That's why I added the Info-tag to the title because I am not sure if this is an environmental issue or caused by code somehow.

What do you mean exactly with

If you want Gitea to behave like an FHS compliant program use the wrapper or recompile. Placing it directly in /usr/local/bin is recipe for gotchas.

Should I move my Gitea-executable to /usr/local/bin, adjust my service file and that fixes my issues? Currently the file is stored in /home/pi/gitea/gitea`.
I will search for the meaning of FHS on Linux (I am not sure what this abbreviation means), maybe I can give some more information then.

@mbedded commented on GitHub (Dec 21, 2019): I am sorry but I didn't understood that in complete :/ In my service I have the following line ``` ExecStart=/home/pi/gitea/gitea web -c /home/pi/gitea/custom/conf/app.ini ``` There is a path to my gitea executable with `-c` giving the configuration file. What confuses me is the fact that `stop service` and `start service` are working after I restarted my device. But downloading the file, adding `chmod +x` and start the service again should be working. I am not entirely sure why this causes an issue. The config file uses absolute paths to avoid issues with relative paths like missing data or data stored in strange places. I am not working with Linux that much yet (only since 6-7 months) so I assumed (coming from a Windows world) there should be no issues when I replace an executable with another one. --- > We should change our documentation to recommend using the FHS compliant wrapper script or rebuilding with the FHS compliant options. If you see some better ways to install or use gitea feel free to adjust the documentation if this fits better than a bugfix within the code. That's why I added the *Info*-tag to the title because I am not sure if this is an environmental issue or caused by code somehow. --- What do you mean exactly with > If you want Gitea to behave like an FHS compliant program use the wrapper or recompile. Placing it directly in /usr/local/bin is recipe for gotchas. Should I move my Gitea-executable to `/usr/local/bin`, adjust my service file and that fixes my issues? Currently the file is stored in /home/pi/gitea/gitea`. I will search for the meaning of FHS on Linux (I am not sure what this abbreviation means), maybe I can give some more information then.
GiteaMirror commented 2025-11-02 05:53:23 -06:00
Author
Owner
Copy Link

@bagasme commented on GitHub (Dec 23, 2019):

@mbedded FHS is Filesystem Hierarchy Standard, which describes common paths for Unix and Unix-like systems (including Linux).

@bagasme commented on GitHub (Dec 23, 2019): @mbedded FHS is *Filesystem Hierarchy Standard*, which describes common paths for Unix and Unix-like systems (including Linux).
GiteaMirror commented 2025-11-02 05:53:23 -06:00
Author
Owner
Copy Link

@zeripath commented on GitHub (Dec 23, 2019):

Sorry I missed your reply @mbedded. My message wasn't necessarily directed at fixing your problem directly.

Let's try to solve your problem before discussing how to prevent this from happening to other people in future.

If I understand correctly, you have:

  • The gitea binary is found in /home/pi/gitea/gitea
  • You normally run gitea using systemd with the above unit file.

In your first comment you don't state that you chmodded the new gitea.

Do you have a gitea in /usr/local/bin ? Is it possible that because gitea was not chmod +x that when systemctl tried to start the program it used that? Or is it possible that when systemctl tried to start the non-executable gitea it had to do some dance that meant that the environment disappeared?

In any case it looks like (re)starting gitea with systemctl did not lead to the environment being passed to gitea - which is weird.

I suggest that instead of referencing the binary directly in the systemd unit you instead download a copy of https://github.com/go-gitea/gitea/blob/master/contrib/fhs-compliant-script/gitea appropriately configured for your install and reference that in the systemd unit file. You could put the script in /usr/local/bin and have the gitea admin commands work from anywhere without having to set -c or an environment.

@zeripath commented on GitHub (Dec 23, 2019): Sorry I missed your reply @mbedded. My message wasn't necessarily directed at fixing your problem directly. Let's try to solve your problem before discussing how to prevent this from happening to other people in future. If I understand correctly, you have: * The gitea binary is found in /home/pi/gitea/gitea * You normally run gitea using systemd with the above unit file. In your first comment you don't state that you chmodded the new gitea. Do you have a gitea in /usr/local/bin ? Is it possible that because gitea was not chmod +x that when systemctl tried to start the program it used that? Or is it possible that when systemctl tried to start the non-executable gitea it had to do some dance that meant that the environment disappeared? In any case it looks like (re)starting gitea with systemctl did not lead to the environment being passed to gitea - which is weird. I suggest that instead of referencing the binary directly in the systemd unit you instead download a copy of https://github.com/go-gitea/gitea/blob/master/contrib/fhs-compliant-script/gitea appropriately configured for your install and reference that in the systemd unit file. You could put the script in /usr/local/bin and have the gitea admin commands work from anywhere without having to set -c or an environment.
GiteaMirror commented 2025-11-02 05:53:23 -06:00
Author
Owner
Copy Link

@mbedded commented on GitHub (Dec 24, 2019):

@bagasme Thank you for that information.

@zeripath that's no problem. Currently there are some holidays, too. So I don't expect an answer within a few days :)
Your list above is correct and describes my current environment.

I have no Gitea-executable in any other path. I missed to mention the chmod +x command in my minimal example above. The execution rights where updated so it can be executed by the service. The ls -lah above shows this:

ls -lah /home/pi/gitea
-rwxr-xr-x  1 pi pi  69M Dec  5 20:21 gitea
-rwxr-xr-x  1 pi pi  83M Sep  7 20:21 gitea.bak

The .bak-file is the "old" gitea file before the update.

For my understanding:

  • I install your linked FHS-compliant script to /usr/bin/gitea.
  • I move my folders and files to the locations mentioned in the FHS-Script
  • Adjust my service-file to use the gitea command without any additional parameters or values for the config-file or working.directory.

I will try to get gitea running with the script and the new file locations. Because of the holidays it could be in the beginning of next year. When I made some progress I will reply to this thread :)

Thank you very much everyone for your help. I hope you have some nice time with your friends and family 🎄

@mbedded commented on GitHub (Dec 24, 2019): @bagasme Thank you for that information. @zeripath that's no problem. Currently there are some holidays, too. So I don't expect an answer within a few days :) Your list above is correct and describes my current environment. I have _no_ Gitea-executable in any other path. I missed to mention the `chmod +x` command in my minimal example above. The execution rights where updated so it can be executed by the service. The `ls -lah` above shows this: > ``` > ls -lah /home/pi/gitea > -rwxr-xr-x 1 pi pi 69M Dec 5 20:21 gitea > -rwxr-xr-x 1 pi pi 83M Sep 7 20:21 gitea.bak > ``` The .bak-file is the "old" gitea file before the update. For my understanding: - I install your linked FHS-compliant script to `/usr/bin/gitea`. - I move my folders and files to the locations mentioned in the FHS-Script - Adjust my service-file to use the `gitea` command without any additional parameters or values for the config-file or working.directory. I will try to get gitea running with the script and the new file locations. Because of the holidays it could be in the beginning of next year. When I made some progress I will reply to this thread :) Thank you very much everyone for your help. I hope you have some nice time with your friends and family 🎄
GiteaMirror commented 2025-11-02 05:53:23 -06:00
Author
Owner
Copy Link

@mbedded commented on GitHub (Jan 16, 2020):

Hello @zeripath and @bagasme,

i found some time within the last days to try and fix my installation as you suggested. I have done the following:

  • Installing your FHS compliant script as mentioned above
  • Moved the gitea executable to /usr/local/bin/gitea
  • Moved the config to /etc/gitea/app.ini
  • Moved my gitea-folders to /var/lib/gitea/gitea-repositories and gitea-lfs
  • Adjusted the paths and calles in my service script in /etc/systemd/system/gitea.service.

I switched some versions with the following example:

cd /usr/local/bin
systemctl stop gitea
mv gitea gitea.bak
wget -O gitea DOWNLOAD_URL_OF_GITEA
chmod +x gitea
systemctl start gitea

Now i was able to change my version as example to 1.7.0 or 1.6.x. Now i switched to the current release of 1.10.2 and the errors mentioned by my first post didn't happen to me. So finally i was able to replace the gitea-executable and restart the service without restarting my Raspberry.

So i assume that using default directories (FHS) for your installation fixes my initial error. As first i upgraded as usual (using my custom directories) and that reproduced the error.

From my point of view we can close this ticket, because it was important to me to inform you that there may be a bug in Gitea because i am not that professional with Go or Linux yet :)
At this point you can decide what to do: I think the easiest thing will be a hint or warning within the documentation that this may appear when the default directories are not used.

I checked the documentation and there you tell about the FHS directories. I just didn't used them because as a new guy it was easier for me to have everything in one place to get started. So it's totally a self made mistake.

Thank you very much for your help and guidance 👍

@mbedded commented on GitHub (Jan 16, 2020): Hello @zeripath and @bagasme, i found some time within the last days to try and fix my installation as you suggested. I have done the following: - Installing your FHS compliant script as mentioned above - Moved the gitea executable to `/usr/local/bin/gitea` - Moved the config to `/etc/gitea/app.ini` - Moved my gitea-folders to `/var/lib/gitea/gitea-repositories` and `gitea-lfs` - Adjusted the paths and calles in my service script in `/etc/systemd/system/gitea.service`. I switched some versions with the following example: ``` cd /usr/local/bin systemctl stop gitea mv gitea gitea.bak wget -O gitea DOWNLOAD_URL_OF_GITEA chmod +x gitea systemctl start gitea ``` Now i was able to change my version as example to 1.7.0 or 1.6.x. Now i switched to the current release of 1.10.2 and the errors mentioned by my first post didn't happen to me. So finally i was able to replace the gitea-executable and restart the service without restarting my Raspberry. So i assume that using default directories (FHS) for your installation fixes my initial error. As first i upgraded as usual (using my custom directories) and that reproduced the error. From my point of view we can close this ticket, because it was important to me to inform you that there *may* be a bug in Gitea because i am not that professional with Go or Linux yet :) At this point you can decide what to do: I think the easiest thing will be a hint or warning within the documentation that this may appear when the default directories are not used. I checked the documentation and there you tell about the FHS directories. I just didn't used them because as a new guy it was easier for me to have everything in one place to get started. So it's totally a self made mistake. Thank you very much for your help and guidance :+1:
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 type/question
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#4519
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?