Fix various typos of software names (#18083)
* `git` -> `Git` * `Github` and `github` -> `GitHub` * `crowdin` -> `Crowdin` * `git-lfs` -> `Git LFS` * `githooks`, `git hooks`, `git-hooks` -> `Git Hooks` * `discord` -> `Discord` * `2fa` -> `2FA` * `gitlab` and `Gitlab` -> `GitLab` * `web hook` -> `webhook` * `linux` -> `Linux` * `sqlite` -> `SQLite` * `MYSQL` and `mysql` -> `MySQL` * rename refs to `master` branch -> `main` * Fix English grammar
This commit is contained in:
qwerty287
GitHub
parent
a5df7ba6bf
commit
5754080eb9
28 changed files with 92 additions and 92 deletions
2
.github/pull_request_template.md
vendored
2
.github/pull_request_template.md
vendored
|
|
@ -3,7 +3,7 @@
|
|||
Please check the following:
|
||||
|
||||
1. Make sure you are targeting the `main` branch, pull requests on release branches are only allowed for bug fixes.
|
||||
2. Read contributing guidelines: https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md
|
||||
2. Read contributing guidelines: https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md
|
||||
3. Describe what your pull request does and which issue you're targeting (if any)
|
||||
|
||||
-->
|
||||
|
|
|
|||
|
|
@ -81,13 +81,13 @@ Here's how to run the test suite:
|
|||
|``make lint-frontend`` | lint frontend files |
|
||||
|``make lint-backend`` | lint backend files |
|
||||
|
||||
- run test code (Suggest run in linux)
|
||||
- run test code (Suggest run in Linux)
|
||||
|
||||
| | |
|
||||
| :------------------------------------- | :----------------------------------------------- |
|
||||
|``make test[\#TestSpecificName]`` | run unit test |
|
||||
|``make test-sqlite[\#TestSpecificName]``| run [integration](integrations) test for sqlite |
|
||||
|[More detail message about integrations](integrations/README.md) |
|
||||
|``make test-sqlite[\#TestSpecificName]``| run [integration](integrations) test for SQLite |
|
||||
|[More details about integrations](integrations/README.md) |
|
||||
|
||||
## Vendoring
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ You can find more information on how to get started with it on the [Modules Wiki
|
|||
## Translation
|
||||
|
||||
We do all translation work inside [Crowdin](https://crowdin.com/project/gitea).
|
||||
The only translation that is maintained in this git repository is
|
||||
The only translation that is maintained in this Git repository is
|
||||
[`en_US.ini`](https://github.com/go-gitea/gitea/blob/master/options/locale/locale_en-US.ini)
|
||||
and is synced regularly to Crowdin. Once a translation has reached
|
||||
A SATISFACTORY PERCENTAGE it will be synced back into this repo and
|
||||
|
|
@ -157,7 +157,7 @@ import (
|
|||
|
||||
## Design guideline
|
||||
|
||||
To maintain understandable code and avoid circular dependencies it is important to have a good structure of the code. The gitea code is divided into the following parts:
|
||||
To maintain understandable code and avoid circular dependencies it is important to have a good structure of the code. The Gitea code is divided into the following parts:
|
||||
|
||||
- **integration:** Integrations tests
|
||||
- **models:** Contains the data structures used by xorm to construct database tables. It also contains supporting functions to query and update the database. Dependencies to other code in Gitea should be avoided although some modules might be needed (for example for logging).
|
||||
|
|
@ -223,7 +223,7 @@ Additionally you could add a line at the end of your commit message.
|
|||
Signed-off-by: Joe Smith <joe.smith@email.com>
|
||||
```
|
||||
|
||||
If you set your `user.name` and `user.email` git configs, you can add the
|
||||
If you set your `user.name` and `user.email` Git configs, you can add the
|
||||
line to the end of your commit automatically with `git commit -s`.
|
||||
|
||||
We assume in good faith that the information you provide is legally binding.
|
||||
|
|
@ -268,7 +268,7 @@ to the maintainers team. If a maintainer is inactive for more than 3
|
|||
months and forgets to leave the maintainers team, the owners may move
|
||||
him or her from the maintainers team to the advisors team.
|
||||
For security reasons, Maintainers should use 2FA for their accounts and
|
||||
if possible provide gpg signed commits.
|
||||
if possible provide GPG signed commits.
|
||||
https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/
|
||||
https://help.github.com/articles/signing-commits-with-gpg/
|
||||
|
||||
|
|
@ -326,13 +326,13 @@ they served:
|
|||
|
||||
## Versions
|
||||
|
||||
Gitea has the `master` branch as a tip branch and has version branches
|
||||
Gitea has the `main` branch as a tip branch and has version branches
|
||||
such as `release/v0.9`. `release/v0.9` is a release branch and we will
|
||||
tag `v0.9.0` for binary download. If `v0.9.0` has bugs, we will accept
|
||||
pull requests on the `release/v0.9` branch and publish a `v0.9.1` tag,
|
||||
after bringing the bug fix also to the master branch.
|
||||
after bringing the bug fix also to the main branch.
|
||||
|
||||
Since the `master` branch is a tip version, if you wish to use Gitea
|
||||
Since the `main` branch is a tip version, if you wish to use Gitea
|
||||
in production, please download the latest release tag version. All the
|
||||
branches will be protected via GitHub, all the PRs to every branch must
|
||||
be reviewed by two maintainers and must pass the automatic tests.
|
||||
|
|
@ -340,14 +340,14 @@ be reviewed by two maintainers and must pass the automatic tests.
|
|||
## Releasing Gitea
|
||||
|
||||
* Let $vmaj, $vmin and $vpat be Major, Minor and Patch version numbers, $vpat should be rc1, rc2, 0, 1, ...... $vmaj.$vmin will be kept the same as milestones on github or gitea in future.
|
||||
* Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody against in about serval hours.
|
||||
* If this is a big version first you have to create PR for changelog on branch `master` with PRs with label `changelog` and after it has been merged do following steps:
|
||||
* Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on Discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody against in about serval hours.
|
||||
* If this is a big version first you have to create PR for changelog on branch `main` with PRs with label `changelog` and after it has been merged do following steps:
|
||||
* Create `-dev` tag as `git tag -s -F release.notes v$vmaj.$vmin.0-dev` and push the tag as `git push origin v$vmaj.$vmin.0-dev`.
|
||||
* When CI has finished building tag then you have to create a new branch named `release/v$vmaj.$vmin`
|
||||
* If it is bugfix version create PR for changelog on branch `release/v$vmaj.$vmin` and wait till it is reviewed and merged.
|
||||
* Add a tag as `git tag -s -F release.notes v$vmaj.$vmin.$`, release.notes file could be a temporary file to only include the changelog this version which you added to `CHANGELOG.md`.
|
||||
* And then push the tag as `git push origin v$vmaj.$vmin.$`. Drone CI will automatically created a release and upload all the compiled binary. (But currently it didn't add the release notes automatically. Maybe we should fix that.)
|
||||
* If needed send PR for changelog on branch `master`.
|
||||
* And then push the tag as `git push origin v$vmaj.$vmin.$`. Drone CI will automatically create a release and upload all the compiled binary. (But currently it doesn't add the release notes automatically. Maybe we should fix that.)
|
||||
* If needed send PR for changelog on branch `main`.
|
||||
* Send PR to [blog repository](https://gitea.com/gitea/blog) announcing the release.
|
||||
|
||||
## Copyright
|
||||
|
|
|
|||
|
|
@ -67,7 +67,7 @@ From the root of the source tree, run:
|
|||
|
||||
TAGS="bindata" make build
|
||||
|
||||
or if sqlite support is required:
|
||||
or if SQLite support is required:
|
||||
|
||||
TAGS="bindata sqlite sqlite_unlock_notify" make build
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ Some jurisdictions (such as EU), requires certain legal pages (e.g. Privacy Poli
|
|||
Gitea source code ships with sample pages, available in `contrib/legal` directory. Copy them to `custom/public/`. For example, to add Privacy Policy:
|
||||
|
||||
```
|
||||
wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/master/contrib/legal/privacy.html.sample
|
||||
wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample
|
||||
```
|
||||
|
||||
Now you need to edit the page to meet your requirements. In particular you must change the email addresses, web addresses and references to "Your Gitea Instance" to match your situation.
|
||||
|
|
|
|||
|
|
@ -60,6 +60,6 @@ git config --global uploadpack.allowfilter true
|
|||
|
||||
See [GitHub blog post: Get up to speed with partial clone](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/)
|
||||
for common use cases of clone filters (blobless and treeless clones), and
|
||||
[Gitlab docs for partial clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html)
|
||||
[GitLab docs for partial clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html)
|
||||
for more advanced use cases (such as filter by file size and remove
|
||||
filters to turn partial clone into full clone).
|
||||
|
|
|
|||
|
|
@ -85,7 +85,7 @@ The default is the current directory.
|
|||
The `--custom` flag tells Gitea to extract the files directly into the `custom` directory.
|
||||
For this to work, the command needs to know the location of the `app.ini` configuration
|
||||
file (`--config`) and, depending of the configuration, be ran from the directory where
|
||||
gitea normally starts. See [Customizing Gitea]({{< relref "doc/advanced/customizing-gitea.en-us.md" >}}) for details.
|
||||
Gitea normally starts. See [Customizing Gitea]({{< relref "doc/advanced/customizing-gitea.en-us.md" >}}) for details.
|
||||
|
||||
The `--overwrite` flag allows any existing files in the destination directory to be overwritten.
|
||||
|
||||
|
|
|
|||
|
|
@ -302,7 +302,7 @@ The following configuration set `Content-Type: application/vnd.android.package-a
|
|||
- `PPROF_DATA_PATH`: **data/tmp/pprof**: `PPROF_DATA_PATH`, use an absolute path when you start Gitea as service
|
||||
- `LANDING_PAGE`: **home**: Landing page for unauthenticated users \[home, explore, organizations, login\].
|
||||
|
||||
- `LFS_START_SERVER`: **false**: Enables git-lfs support.
|
||||
- `LFS_START_SERVER`: **false**: Enables Git LFS support.
|
||||
- `LFS_CONTENT_PATH`: **%(APP_DATA_PATH)/lfs**: Default LFS content path. (if it is on local storage.) **DEPRECATED** use settings in `[lfs]`.
|
||||
- `LFS_JWT_SECRET`: **\<empty\>**: LFS authentication secret, change this a unique string.
|
||||
- `LFS_HTTP_AUTH_EXPIRY`: **20m**: LFS authentication validity period in time.Duration, pushes taking longer than this may fail.
|
||||
|
|
@ -378,7 +378,7 @@ The following configuration set `Content-Type: application/vnd.android.package-a
|
|||
- `require`: Enable TLS without any verifications.
|
||||
- `verify-ca`: Enable TLS with verification of the database server certificate against its root certificate.
|
||||
- `verify-full`: Enable TLS and verify the database server name matches the given certificate in either the `Common Name` or `Subject Alternative Name` fields.
|
||||
- `SQLITE_TIMEOUT`: **500**: Query timeout for sqlite3 only.
|
||||
- `SQLITE_TIMEOUT`: **500**: Query timeout for SQLite3 only.
|
||||
- `ITERATE_BUFFER_SIZE`: **50**: Internal buffer size for iterating.
|
||||
- `CHARSET`: **utf8mb4**: For MySQL only, either "utf8" or "utf8mb4". NOTICE: for "utf8mb4" you must use MySQL InnoDB > 5.6. Gitea is unable to check this.
|
||||
- `PATH`: **data/gitea.db**: For SQLite3 only, the database file path.
|
||||
|
|
@ -490,8 +490,8 @@ Certain queues have defaults that override the defaults set in `[queue]` (this o
|
|||
- `REVERSE_PROXY_LIMIT`: **1**: Interpret X-Forwarded-For header or the X-Real-IP header and set this as the remote IP for the request.
|
||||
Number of trusted proxy count. Set to zero to not use these headers.
|
||||
- `REVERSE_PROXY_TRUSTED_PROXIES`: **127.0.0.0/8,::1/128**: List of IP addresses and networks separated by comma of trusted proxy servers. Use `*` to trust all.
|
||||
- `DISABLE_GIT_HOOKS`: **true**: Set to `false` to enable users with git hook privilege to create custom git hooks.
|
||||
WARNING: Custom git hooks can be used to perform arbitrary code execution on the host operating system.
|
||||
- `DISABLE_GIT_HOOKS`: **true**: Set to `false` to enable users with Git Hook privilege to create custom Git Hooks.
|
||||
WARNING: Custom Git Hooks can be used to perform arbitrary code execution on the host operating system.
|
||||
This enables the users to access and modify this config file and the Gitea database and interrupt the Gitea service.
|
||||
By modifying the Gitea database, users can gain Gitea administrator privileges.
|
||||
It also enables them to access other resources available to the user on the operating system that is running the
|
||||
|
|
@ -595,7 +595,7 @@ Certain queues have defaults that override the defaults set in `[queue]` (this o
|
|||
- `DEFAULT_ORG_MEMBER_VISIBLE`: **false** True will make the membership of the users visible when added to the organisation.
|
||||
- `ALLOW_ONLY_INTERNAL_REGISTRATION`: **false** Set to true to force registration only via Gitea.
|
||||
- `ALLOW_ONLY_EXTERNAL_REGISTRATION`: **false** Set to true to force registration only using third-party services.
|
||||
- `NO_REPLY_ADDRESS`: **noreply.DOMAIN** Value for the domain part of the user's email address in the git log if user has set KeepEmailPrivate to true. DOMAIN resolves to the value in server.DOMAIN.
|
||||
- `NO_REPLY_ADDRESS`: **noreply.DOMAIN** Value for the domain part of the user's email address in the Git log if user has set KeepEmailPrivate to true. DOMAIN resolves to the value in server.DOMAIN.
|
||||
The user's email will be replaced with a concatenation of the user name in lower case, "@" and NO_REPLY_ADDRESS.
|
||||
- `USER_DELETE_WITH_COMMENTS_MAX_TIME`: **0** Minimum amount of time a user must exist before comments are kept when the user is deleted.
|
||||
- `VALID_SITE_URL_SCHEMES`: **http, https**: Valid site url schemes for user profiles
|
||||
|
|
@ -658,7 +658,7 @@ Define allowed algorithms and their minimum key length (use -1 to disable a type
|
|||
- `MAILER_TYPE`: **smtp**: \[smtp, sendmail, dummy\]
|
||||
- **smtp** Use SMTP to send mail
|
||||
- **sendmail** Use the operating system's `sendmail` command instead of SMTP.
|
||||
This is common on linux systems.
|
||||
This is common on Linux systems.
|
||||
- **dummy** Send email messages to the log as a testing phase.
|
||||
- Note that enabling sendmail will ignore all other `mailer` settings except `ENABLED`,
|
||||
`FROM`, `SUBJECT_PREFIX` and `SENDMAIL_PATH`.
|
||||
|
|
@ -918,7 +918,7 @@ NB: You must have `DISABLE_ROUTER_LOG` set to `false` for this option to take ef
|
|||
|
||||
## Git (`git`)
|
||||
|
||||
- `PATH`: **""**: The path of git executable. If empty, Gitea searches through the PATH environment.
|
||||
- `PATH`: **""**: The path of Git executable. If empty, Gitea searches through the PATH environment.
|
||||
- `DISABLE_DIFF_HIGHLIGHT`: **false**: Disables highlight of added and removed changes.
|
||||
- `MAX_GIT_DIFF_LINES`: **1000**: Max number of lines allowed of a single file in diff view.
|
||||
- `MAX_GIT_DIFF_LINE_CHARACTERS`: **5000**: Max character count per line highlighted in diff view.
|
||||
|
|
@ -926,7 +926,7 @@ NB: You must have `DISABLE_ROUTER_LOG` set to `false` for this option to take ef
|
|||
- `COMMITS_RANGE_SIZE`: **50**: Set the default commits range size
|
||||
- `BRANCHES_RANGE_SIZE`: **20**: Set the default branches range size
|
||||
- `GC_ARGS`: **\<empty\>**: Arguments for command `git gc`, e.g. `--aggressive --auto`. See more on http://git-scm.com/docs/git-gc/
|
||||
- `ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: If use git wire protocol version 2 when git version >= 2.18, default is true, set to false when you always want git wire protocol version 1
|
||||
- `ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: If use Git wire protocol version 2 when Git version >= 2.18, default is true, set to false when you always want Git wire protocol version 1
|
||||
- `PULL_REQUEST_PUSH_MESSAGE`: **true**: Respond to pushes to a non-default branch with a URL for creating a Pull Request (if the repository has them enabled)
|
||||
- `VERBOSE_PUSH`: **true**: Print status information about pushes as they are being processed.
|
||||
- `VERBOSE_PUSH_DELAY`: **5s**: Only print verbose information if push takes longer than this delay.
|
||||
|
|
@ -952,7 +952,7 @@ NB: You must have `DISABLE_ROUTER_LOG` set to `false` for this option to take ef
|
|||
- `ENABLE_SWAGGER`: **true**: Enables /api/swagger, /api/v1/swagger etc. endpoints. True or false; default is true.
|
||||
- `MAX_RESPONSE_ITEMS`: **50**: Max number of items in a page.
|
||||
- `DEFAULT_PAGING_NUM`: **30**: Default paging number of API.
|
||||
- `DEFAULT_GIT_TREES_PER_PAGE`: **1000**: Default and maximum number of items per page for git trees API.
|
||||
- `DEFAULT_GIT_TREES_PER_PAGE`: **1000**: Default and maximum number of items per page for Git trees API.
|
||||
- `DEFAULT_MAX_BLOB_SIZE`: **10485760**: Default max size of a blob that can be return by the blobs API.
|
||||
|
||||
## OAuth2 (`oauth2`)
|
||||
|
|
|
|||
|
|
@ -287,7 +287,7 @@ To add a custom license, add a file with the license text to `$GITEA_CUSTOM/opti
|
|||
|
||||
### Locales
|
||||
|
||||
Locales are managed via our [crowdin](https://crowdin.com/project/gitea).
|
||||
Locales are managed via our [Crowdin](https://crowdin.com/project/gitea).
|
||||
You can override a locale by placing an altered locale file in `$GITEA_CUSTOM/options/locale`.
|
||||
Gitea's default locale files can be found in the [`options/locale`](https://github.com/go-gitea/gitea/tree/main/options/locale) source folder and these should be used as examples for your changes.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ menu:
|
|||
|
||||
# Protected tags
|
||||
|
||||
Protected tags allow control over who has permission to create or update git tags. Each rule allows you to match either an individual tag name, or use an appropriate pattern to control multiple tags at once.
|
||||
Protected tags allow control over who has permission to create or update Git tags. Each rule allows you to match either an individual tag name, or use an appropriate pattern to control multiple tags at once.
|
||||
|
||||
**Table of Contents**
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ menu:
|
|||
|
||||
Gitea will verify GPG commit signatures in the provided tree by
|
||||
checking if the commits are signed by a key within the Gitea database,
|
||||
or if the commit matches the default key for git.
|
||||
or if the commit matches the default key for Git.
|
||||
|
||||
Keys are not checked to determine if they have expired or revoked.
|
||||
Keys are also not checked with keyservers.
|
||||
|
|
@ -33,8 +33,8 @@ it is reported to be signed with a key with an id.
|
|||
Please note: The signer of a commit does not have to be an author or
|
||||
committer of a commit.
|
||||
|
||||
This functionality requires git >= 1.7.9 but for full functionality
|
||||
this requires git >= 2.0.0.
|
||||
This functionality requires Git >= 1.7.9 but for full functionality
|
||||
this requires Git >= 2.0.0.
|
||||
|
||||
## Automatic Signing
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ It is up to a server administrator to determine how best to install
|
|||
a signing key. Gitea generates all its commits using the server `git`
|
||||
command at present - and therefore the server `gpg` will be used for
|
||||
signing (if configured.) Administrators should review best-practices
|
||||
for gpg - in particular it is probably advisable to only install a
|
||||
for GPG - in particular it is probably advisable to only install a
|
||||
signing secret subkey without the master signing and certifying secret
|
||||
key.
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ The `default` option will interrogate `git config` for
|
|||
`commit.gpgsign` option - if this is set, then it will use the results
|
||||
of the `user.signingkey`, `user.name` and `user.email` as appropriate.
|
||||
|
||||
Please note: by adjusting git's `config` file within Gitea's
|
||||
Please note: by adjusting Git's `config` file within Gitea's
|
||||
repositories, `SIGNING_KEY=default` could be used to provide different
|
||||
signing keys on a per-repository basis. However, this is clearly not an
|
||||
ideal UI and therefore subject to change.
|
||||
|
|
|
|||
|
|
@ -110,8 +110,8 @@ the `token=` string in a GET request.
|
|||
|
||||
API Reference guide is auto-generated by swagger and available on:
|
||||
`https://gitea.your.host/api/swagger`
|
||||
or on
|
||||
[gitea demo instance](https://try.gitea.io/api/swagger)
|
||||
or on the
|
||||
[Gitea demo instance](https://try.gitea.io/api/swagger)
|
||||
|
||||
The OpenAPI document is at:
|
||||
`https://gitea.your.host/swagger.v1.json`
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ So it's very important to manage these packages. Please take the below guideline
|
|||
To maintain understandable code and avoid circular dependencies it is important to have a good code structure. The Gitea backend is divided into the following parts:
|
||||
|
||||
- `build`: Scripts to help build Gitea.
|
||||
- `cmd`: All Gitea actual sub commands includes web, doctor, serv, hooks, admin and etc. `web` will start the web service. `serv` and `hooks` will be invoked by git or openSSH. Other sub commands could help to maintain Gitea.
|
||||
- `cmd`: All Gitea actual sub commands includes web, doctor, serv, hooks, admin and etc. `web` will start the web service. `serv` and `hooks` will be invoked by Git or OpenSSH. Other sub commands could help to maintain Gitea.
|
||||
- `integrations`: Integration tests
|
||||
- `models`: Contains the data structures used by xorm to construct database tables. It also contains functions to query and update the database. Dependencies to other Gitea code should be avoided. You can make exceptions in cases such as logging.
|
||||
- `models/db`: Basic database operations. All other `models/xxx` packages should depend on this package. The `GetEngine` function should only be invoked from `models/`.
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ One of these three distributions of Make will run on Windows:
|
|||
- The binary is called `mingw32-make.exe` instead of `make.exe`. Add the `bin` folder to `PATH`.
|
||||
- [Chocolatey package](https://chocolatey.org/packages/make). Run `choco install make`
|
||||
|
||||
**Note**: If you are attempting to build using make with Windows Command Prompt, you may run into issues. The above prompts (git bash, or mingw) are recommended, however if you only have command prompt (or potentially powershell) you can set environment variables using the [set](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) command, e.g. `set TAGS=bindata`.
|
||||
**Note**: If you are attempting to build using make with Windows Command Prompt, you may run into issues. The above prompts (Git bash, or MinGW) are recommended, however if you only have command prompt (or potentially PowerShell) you can set environment variables using the [set](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) command, e.g. `set TAGS=bindata`.
|
||||
|
||||
## Downloading and cloning the Gitea source code
|
||||
|
||||
|
|
@ -264,7 +264,7 @@ in `models/migrations/`. You can ensure that your migrations work for the main
|
|||
database types using:
|
||||
|
||||
```bash
|
||||
make test-sqlite-migration # with sqlite switched for the appropriate database
|
||||
make test-sqlite-migration # with SQLite switched for the appropriate database
|
||||
```
|
||||
|
||||
## Testing
|
||||
|
|
@ -282,7 +282,7 @@ have written integration tests; however, these are database dependent.
|
|||
TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite
|
||||
```
|
||||
|
||||
will run the integration tests in an sqlite environment. Integration tests
|
||||
will run the integration tests in an SQLite environment. Integration tests
|
||||
require `git lfs` to be installed. Other database tests are available but
|
||||
may need adjustment to the local environment.
|
||||
|
||||
|
|
@ -308,7 +308,7 @@ make trans-copy clean build
|
|||
```
|
||||
|
||||
You will require a copy of [Hugo](https://gohugo.io/) to run this task. Please
|
||||
note: this may generate a number of untracked git objects, which will need to
|
||||
note: this may generate a number of untracked Git objects, which will need to
|
||||
be cleaned up.
|
||||
|
||||
## Visual Studio Code
|
||||
|
|
|
|||
|
|
@ -16,16 +16,16 @@ menu:
|
|||
# Migration Features
|
||||
|
||||
Complete migrations were introduced in Gitea 1.9.0. It defines two interfaces to support migrating
|
||||
repository data from other git host platforms to Gitea or, in the future, migrating Gitea data to other
|
||||
git host platforms.
|
||||
Currently, migrations from Github, Gitlab, and other Gitea instances are implemented.
|
||||
repository data from other Git host platforms to Gitea or, in the future, migrating Gitea data to other
|
||||
Git host platforms.
|
||||
Currently, migrations from GitHub, GitLab, and other Gitea instances are implemented.
|
||||
|
||||
First of all, Gitea defines some standard objects in packages [modules/migration](https://github.com/go-gitea/gitea/tree/main/modules/migration).
|
||||
They are `Repository`, `Milestone`, `Release`, `ReleaseAsset`, `Label`, `Issue`, `Comment`, `PullRequest`, `Reaction`, `Review`, `ReviewComment`.
|
||||
|
||||
## Downloader Interfaces
|
||||
|
||||
To migrate from a new git host platform, there are two steps to be updated.
|
||||
To migrate from a new Git host platform, there are two steps to be updated.
|
||||
|
||||
- You should implement a `Downloader` which will be used to get repository information.
|
||||
- You should implement a `DownloaderFactory` which will be used to detect if the URL matches and create the above `Downloader`.
|
||||
|
|
|
|||
|
|
@ -111,7 +111,7 @@ Adds the following fields:
|
|||
the LDAP server. The default period is every 24 hours but that can be
|
||||
changed in the app.ini file. See the _cron.sync_external_users_ section in
|
||||
the [sample
|
||||
app.ini](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.example.ini)
|
||||
app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
for detailed comments about that section. The _User Search Base_ and _User
|
||||
Filter_ settings described above will limit which users can use Gitea and
|
||||
which users will be synchronized. When initially run the task will create
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ menu:
|
|||
|
||||
# Webhooks
|
||||
|
||||
Gitea supports web hooks for repository events. This can be configured in the settings
|
||||
Gitea supports webhooks for repository events. This can be configured in the settings
|
||||
page `/:username/:reponame/settings/hooks` by a repository admin. Webhooks can also be configured on a per-organization and whole system basis.
|
||||
All event pushes are POST requests. The methods currently supported are:
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ On our [downloads page](https://dl.gitea.io/gitea/) you will see a 1.7 directory
|
|||
The 1.7 and 1.7.0 directories are **not** the same. The 1.7 directory is built on each merged commit to the [`release/v1.7`](https://github.com/go-gitea/gitea/tree/release/v1.7) branch.
|
||||
The 1.7.0 directory, however, is a build that was created when the [`v1.7.0`](https://github.com/go-gitea/gitea/releases/tag/v1.7.0) tag was created.
|
||||
|
||||
This means that 1.x downloads will change as commits are merged to their respective branch (think of it as a separate "master" branch for each release).
|
||||
This means that 1.x downloads will change as commits are merged to their respective branch (think of it as a separate "main" branch for each release).
|
||||
On the other hand, 1.x.x downloads should never change.
|
||||
|
||||
## How to migrate from Gogs/GitHub/etc. to Gitea
|
||||
|
|
@ -45,7 +45,7 @@ To migrate from GitHub to Gitea, you can use Gitea's built-in migration form.
|
|||
In order to migrate items such as issues, pull requests, etc. you will need to input at least your username.
|
||||
[Example (requires login)](https://try.gitea.io/repo/migrate)
|
||||
|
||||
To migrate from Gitlab to Gitea, you can use this non-affiliated tool:
|
||||
To migrate from GitLab to Gitea, you can use this non-affiliated tool:
|
||||
https://github.com/loganinak/MigrateGitlabToGogs
|
||||
|
||||
## Where does Gitea store what file
|
||||
|
|
@ -229,7 +229,7 @@ following things:
|
|||
- On the client:
|
||||
- Ensure the public and private ssh keys are added to the correct Gitea user.
|
||||
- Make sure there are no issues in the remote url. In particular, ensure the name of the
|
||||
git user (before the `@`) is spelled correctly.
|
||||
Git user (before the `@`) is spelled correctly.
|
||||
- Ensure public and private ssh keys are correct on client machine.
|
||||
- On the server:
|
||||
- Make sure the repository exists and is correctly named.
|
||||
|
|
|
|||
|
|
@ -33,7 +33,7 @@ chmod +x gitea
|
|||
|
||||
## Verify GPG signature
|
||||
Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries.
|
||||
To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the gpg command line tool.
|
||||
To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the GPG command line tool.
|
||||
|
||||
```sh
|
||||
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
|
||||
|
|
@ -146,7 +146,7 @@ Older Linux distributions (such as Debian 7 and CentOS 6) may not be able to loa
|
|||
Gitea binary, usually producing an error such as ```./gitea: /lib/x86_64-linux-gnu/libc.so.6:
|
||||
version `GLIBC\_2.14' not found (required by ./gitea)```. This is due to the integrated
|
||||
SQLite support in the binaries provided by dl.gitea.io. In this situation, it is usually
|
||||
possible to [install from source]({{< relref "from-source.en-us.md" >}}) without sqlite
|
||||
possible to [install from source]({{< relref "from-source.en-us.md" >}}) without SQLite
|
||||
support.
|
||||
|
||||
### Running Gitea on another port
|
||||
|
|
@ -168,7 +168,7 @@ please remove after fixing the arm7 bug
|
|||
### Git error after updating to a new version of Gitea
|
||||
|
||||
If the binary file name has been changed during the update to a new version of Gitea,
|
||||
git hooks in existing repositories will not work any more. In that case, a git
|
||||
Git Hooks in existing repositories will not work any more. In that case, a Git
|
||||
error will be displayed when pushing to the repository.
|
||||
|
||||
```
|
||||
|
|
@ -180,7 +180,7 @@ binary.
|
|||
|
||||
To solve this, go to the admin options and run the task `Resynchronize pre-receive,
|
||||
update and post-receive hooks of all repositories` to update all hooks to contain
|
||||
the new binary path. Please note that this overwrite all git hooks including ones
|
||||
the new binary path. Please note that this overwrite all Git Hooks including ones
|
||||
with customizations made.
|
||||
|
||||
If you aren't using the built-in to Gitea SSH server you will also need to re-write
|
||||
|
|
|
|||
|
|
@ -43,8 +43,8 @@ Gitea</a>
|
|||
## Download
|
||||
|
||||
First, we must retrieve the source code. Since, the advent of go modules, the
|
||||
simplest way of doing this is to use git directly as we no longer have to have
|
||||
gitea built from within the GOPATH.
|
||||
simplest way of doing this is to use Git directly as we no longer have to have
|
||||
Gitea built from within the GOPATH.
|
||||
|
||||
```bash
|
||||
git clone https://github.com/go-gitea/gitea
|
||||
|
|
@ -101,7 +101,7 @@ Depending on requirements, the following build tags can be included.
|
|||
- `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can
|
||||
be used to authenticate local users or extend authentication to methods
|
||||
available to PAM.
|
||||
* `gogit`: (EXPERIMENTAL) Use go-git variants of git commands.
|
||||
* `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
|
||||
|
||||
Bundling assets into the binary using the `bindata` build tag is recommended for
|
||||
production deployments. It is possible to serve the static assets directly via a reverse proxy,
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ You can run Gitea as service, using either systemd or supervisor. The steps belo
|
|||
|
||||
#### Using systemd
|
||||
|
||||
Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor.
|
||||
Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor.
|
||||
|
||||
Uncomment any service that needs to be enabled on this host, such as MySQL.
|
||||
|
||||
|
|
@ -51,10 +51,10 @@ mkdir /home/git/gitea/log/supervisor
|
|||
```
|
||||
|
||||
Append the configuration from the sample
|
||||
[supervisord config](https://github.com/go-gitea/gitea/blob/master/contrib/supervisor/gitea) to `/etc/supervisor/supervisord.conf`.
|
||||
[supervisord config](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea) to `/etc/supervisor/supervisord.conf`.
|
||||
|
||||
Using your favorite editor, change the user (git) and home
|
||||
(/home/git) settings to match the deployment environment. Change the PORT
|
||||
Using your favorite editor, change the user (`git`) and home
|
||||
(`/home/git`) settings to match the deployment environment. Change the PORT
|
||||
or remove the -p flag if default port is used.
|
||||
|
||||
Lastly enable and start supervisor at boot:
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ COMPUTERNAME is whatever the response is from `echo %COMPUTERNAME%` on the comma
|
|||
|
||||
## Use absolute paths
|
||||
|
||||
If you use sqlite3, change the `PATH` to include the full path:
|
||||
If you use SQLite3, change the `PATH` to include the full path:
|
||||
|
||||
```
|
||||
[database]
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ Gitea provides automatically updated Docker images within its Docker Hub organiz
|
|||
possible to always use the latest stable tag or to use another service that handles updating
|
||||
Docker images.
|
||||
|
||||
The rootless image use Gitea internal ssh to provide git protocol and doesn't support openssh.
|
||||
The rootless image use Gitea internal SSH to provide Git protocol and doesn't support OpenSSH.
|
||||
|
||||
This reference setup guides users through the setup based on `docker-compose`, but the installation
|
||||
of `docker-compose` is out of scope of this documentation. To install `docker-compose` itself, follow
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ services:
|
|||
|
||||
## Ports
|
||||
|
||||
To bind the integrated openSSH daemon and the webserver on a different port, adjust
|
||||
To bind the integrated OpenSSH daemon and the webserver on a different port, adjust
|
||||
the port section. It's common to just change the host port and keep the ports within
|
||||
the container like they are.
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ menu:
|
|||
|
||||
# Backup and Restore
|
||||
|
||||
Gitea currently has a `dump` command that will save the installation to a zip file. This
|
||||
Gitea currently has a `dump` command that will save the installation to a ZIP file. This
|
||||
file can be unpacked and used to restore an instance.
|
||||
|
||||
**Table of Contents**
|
||||
|
|
@ -40,7 +40,7 @@ Inside the `gitea-dump-1482906742.zip` file, will be the following:
|
|||
|
||||
- `app.ini` - Optional copy of configuration file if originally stored outside of the default `custom/` directory
|
||||
- `custom` - All config or customization files in `custom/`.
|
||||
- `data` - Data directory in <GITEA_WORK_DIR>, except sessions if you are using file session. This directory includes `attachments`, `avatars`, `lfs`, `indexers`, sqlite file if you are using sqlite.
|
||||
- `data` - Data directory in <GITEA_WORK_DIR>, except sessions if you are using file session. This directory includes `attachments`, `avatars`, `lfs`, `indexers`, SQLite file if you are using SQLite.
|
||||
- `gitea-db.sql` - SQL dump of database
|
||||
- `gitea-repo.zip` - Complete copy of the repository directory.
|
||||
- `log/` - Various logs. They are not needed for a recovery or migration.
|
||||
|
|
@ -90,8 +90,8 @@ psql -U $USER -d $DATABASE < gitea-db.sql
|
|||
service gitea restart
|
||||
```
|
||||
|
||||
Repository git-hooks should be regenerated if installation method is changed (eg. binary -> Docker), or if Gitea is installed to a different directory than the previous installation.
|
||||
Repository Git Hooks should be regenerated if installation method is changed (eg. binary -> Docker), or if Gitea is installed to a different directory than the previous installation.
|
||||
|
||||
With Gitea running, and from the directory Gitea's binary is located, execute: `./gitea admin regenerate hooks`
|
||||
|
||||
This ensures that application and configuration file paths in repository git-hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail.
|
||||
This ensures that application and configuration file paths in repository Git Hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail.
|
||||
|
|
|
|||
|
|
@ -101,7 +101,7 @@ Admin operations:
|
|||
- `gitea admin user change-password --username myname --password asecurepassword`
|
||||
- `regenerate`
|
||||
- Options:
|
||||
- `hooks`: Regenerate git-hooks for all repositories
|
||||
- `hooks`: Regenerate Git Hooks for all repositories
|
||||
- `keys`: Regenerate authorized_keys file
|
||||
- Examples:
|
||||
- `gitea admin regenerate hooks`
|
||||
|
|
@ -129,7 +129,7 @@ Admin operations:
|
|||
- `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub).
|
||||
- `--custom-email-url`: Use a custom Email URL (option for GitHub).
|
||||
- `--icon-url`: Custom icon URL for OAuth2 login source.
|
||||
- `--override-local-2fa`: Allow source to override local 2fa. (Optional)
|
||||
- `--override-local-2fa`: Allow source to override local 2FA. (Optional)
|
||||
- `--scopes`: Addtional scopes to request for this OAuth2 source. (Optional)
|
||||
- `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional)
|
||||
- `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional)
|
||||
|
|
@ -152,7 +152,7 @@ Admin operations:
|
|||
- `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub).
|
||||
- `--custom-email-url`: Use a custom Email URL (option for GitHub).
|
||||
- `--icon-url`: Custom icon URL for OAuth2 login source.
|
||||
- `--override-local-2fa`: Allow source to override local 2fa. (Optional)
|
||||
- `--override-local-2fa`: Allow source to override local 2FA. (Optional)
|
||||
- `--scopes`: Addtional scopes to request for this OAuth2 source.
|
||||
- `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional)
|
||||
- `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional)
|
||||
|
|
@ -479,7 +479,7 @@ Manage running server operations:
|
|||
|
||||
### dump-repo
|
||||
|
||||
Dump-repo dumps repository data from git/github/gitea/gitlab:
|
||||
Dump-repo dumps repository data from Git/GitHub/Gitea/GitLab:
|
||||
|
||||
- Options:
|
||||
- `--git_service service` : Git service, it could be `git`, `github`, `gitea`, `gitlab`, If clone_addr could be recognized, this could be ignored.
|
||||
|
|
|
|||
|
|
@ -75,7 +75,7 @@ Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
|
|||
- MSSQL (>=2008R2 SP3)
|
||||
- TiDB (MySQL protocol)
|
||||
- Configuration file
|
||||
- [app.ini](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.example.ini)
|
||||
- [app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
|
||||
- Admin panel
|
||||
- Statistics
|
||||
- Actions
|
||||
|
|
@ -99,7 +99,7 @@ Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
|
|||
- Maximum repositories
|
||||
- Disable account
|
||||
- Admin permissions
|
||||
- Permission to create git hooks
|
||||
- Permission to create Git Hooks
|
||||
- Permission to create organizations
|
||||
- Permission to import repositories
|
||||
- Organization management
|
||||
|
|
@ -127,7 +127,7 @@ Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
|
|||
- Clean up old archives
|
||||
- Environment variables
|
||||
- Command line options
|
||||
- Multi-language support ([21 languages](https://github.com/go-gitea/gitea/tree/master/options/locale))
|
||||
- Multi-language support ([21 languages](https://github.com/go-gitea/gitea/tree/main/options/locale))
|
||||
- [Mermaid](https://mermaidjs.github.io/) Diagram support
|
||||
- Mail service
|
||||
- Notifications
|
||||
|
|
@ -247,7 +247,7 @@ Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
|
|||
- Default branch
|
||||
- Branch protection
|
||||
- Webhooks
|
||||
- Git hooks
|
||||
- Git Hooks
|
||||
- Deploy keys
|
||||
|
||||
## System Requirements
|
||||
|
|
@ -257,8 +257,8 @@ Windows, on architectures like amd64, i386, ARM, PowerPC, and others.
|
|||
- Gitea should be run with a dedicated non-root system account on UNIX-type systems.
|
||||
- Note: Gitea manages the `~/.ssh/authorized_keys` file. Running Gitea as a regular user could break that user's ability to log in.
|
||||
- [Git](https://git-scm.com/) version 1.7.2 or later is required. Version 1.9.0 or later is recommended. Also please note:
|
||||
- Git [large file storage](https://git-lfs.github.com/) will be available if enabled when git >= 2.1.2.
|
||||
- Git commit-graph rendering will be enabled automatically when git >= 2.18.
|
||||
- [Git Large File Storage](https://git-lfs.github.com/) will be available if enabled when Git >= 2.1.2.
|
||||
- Git commit-graph rendering will be enabled automatically when Git >= 2.18.
|
||||
|
||||
## Browser Support
|
||||
|
||||
|
|
|
|||
|
|
@ -24,8 +24,8 @@ Start tests
|
|||
make test-sqlite
|
||||
```
|
||||
|
||||
## Run mysql integrations tests
|
||||
Setup a mysql database inside docker
|
||||
## Run MySQL integrations tests
|
||||
Setup a MySQL database inside docker
|
||||
```
|
||||
docker run -e "MYSQL_DATABASE=test" -e "MYSQL_ALLOW_EMPTY_PASSWORD=yes" -p 3306:3306 --rm --name mysql mysql:latest #(just ctrl-c to stop db and clean the container)
|
||||
docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --rm --name elasticsearch elasticsearch:7.6.0 #(in a second terminal, just ctrl-c to stop db and clean the container)
|
||||
|
|
@ -59,13 +59,13 @@ TEST_MSSQL_HOST=localhost:1433 TEST_MSSQL_DBNAME=gitea_test TEST_MSSQL_USERNAME=
|
|||
|
||||
Example command to run GPG test:
|
||||
|
||||
For sqlite:
|
||||
For SQLite:
|
||||
|
||||
```
|
||||
make test-sqlite#GPG
|
||||
```
|
||||
|
||||
For other databases(replace MSSQL to MYSQL, MYSQL8, PGSQL):
|
||||
For other databases(replace `mssql` to `mysql`, `mysql8` or `pgsql`):
|
||||
|
||||
```
|
||||
TEST_MSSQL_HOST=localhost:1433 TEST_MSSQL_DBNAME=test TEST_MSSQL_USERNAME=sa TEST_MSSQL_PASSWORD=MwantsaSecurePassword1 make test-mssql#GPG
|
||||
|
|
|
|||
|
|
@ -881,7 +881,7 @@ desc.archived = Archived
|
|||
template.items = Template Items
|
||||
template.git_content = Git Content (Default Branch)
|
||||
template.git_hooks = Git Hooks
|
||||
template.git_hooks_tooltip = You are currently unable to modify or remove git hooks once added. Select this only if you trust the template repository.
|
||||
template.git_hooks_tooltip = You are currently unable to modify or remove Git Hooks once added. Select this only if you trust the template repository.
|
||||
template.webhooks = Webhooks
|
||||
template.topics = Topics
|
||||
template.avatar = Avatar
|
||||
|
|
@ -919,7 +919,7 @@ migrate_items_releases = Releases
|
|||
migrate_repo = Migrate Repository
|
||||
migrate.clone_address = Migrate / Clone From URL
|
||||
migrate.clone_address_desc = The HTTP(S) or Git 'clone' URL of an existing repository
|
||||
migrate.github_token_desc = You can put one or more tokens with comma separated here to make migrating faster because of Github API rate limit. WARN: Abusing this feature may violate the service provider's policy and lead to account blocking.
|
||||
migrate.github_token_desc = You can put one or more tokens with comma separated here to make migrating faster because of GitHub API rate limit. WARN: Abusing this feature may violate the service provider's policy and lead to account blocking.
|
||||
migrate.clone_local_path = or a local server path
|
||||
migrate.permission_denied = You are not allowed to import local repositories.
|
||||
migrate.permission_denied_blocked = You can not import from disallowed hosts, please ask the admin to check ALLOWED_DOMAINS/ALLOW_LOCALNETWORKS/BLOCKED_DOMAINS settings.
|
||||
|
|
@ -934,7 +934,7 @@ migrate.migrating = Migrating from <b>%s</b> ...
|
|||
migrate.migrating_failed = Migrating from <b>%s</b> failed.
|
||||
migrate.migrating_failed.error = Error: %s
|
||||
migrate.migrating_failed_no_addr = Migration failed.
|
||||
migrate.github.description = Migrate data from github.com or other Github instances.
|
||||
migrate.github.description = Migrate data from github.com or other GitHub instances.
|
||||
migrate.git.description = Migrate a repository only from any Git service.
|
||||
migrate.gitlab.description = Migrate data from gitlab.com or other GitLab instances.
|
||||
migrate.gitea.description = Migrate data from gitea.com or other Gitea instances.
|
||||
|
|
@ -970,7 +970,7 @@ clone_this_repo = Clone this repository
|
|||
create_new_repo_command = Creating a new repository on the command line
|
||||
push_exist_repo = Pushing an existing repository from the command line
|
||||
empty_message = This repository does not contain any content.
|
||||
broken_message = The git data underlying this repository cannot be read. Contact the administrator of this instance or delete this repository.
|
||||
broken_message = The Git data underlying this repository cannot be read. Contact the administrator of this instance or delete this repository.
|
||||
|
||||
code = Code
|
||||
code.desc = Access source code, files, commits and branches.
|
||||
|
|
@ -1066,8 +1066,8 @@ editor.commit_empty_file_text = The file you're about to commit is empty. Procee
|
|||
editor.no_changes_to_show = There are no changes to show.
|
||||
editor.fail_to_update_file = Failed to update/create file '%s'.
|
||||
editor.fail_to_update_file_summary = Error Message:
|
||||
editor.push_rejected_no_message = The change was rejected by the server without a message. Please check githooks.
|
||||
editor.push_rejected = The change was rejected by the server. Please check githooks.
|
||||
editor.push_rejected_no_message = The change was rejected by the server without a message. Please check Git Hooks.
|
||||
editor.push_rejected = The change was rejected by the server. Please check Git Hooks.
|
||||
editor.push_rejected_summary = Full Rejection Message:
|
||||
editor.add_subdir = Add a directory…
|
||||
editor.unable_to_upload_files = Failed to upload files to '%s' with error: %v
|
||||
|
|
@ -1507,9 +1507,9 @@ pulls.rebase_conflict_summary = Error Message
|
|||
pulls.unrelated_histories = Merge Failed: The merge head and base do not share a common history. Hint: Try a different strategy
|
||||
pulls.merge_out_of_date = Merge Failed: Whilst generating the merge, the base was updated. Hint: Try again.
|
||||
pulls.head_out_of_date = Merge Failed: Whilst generating the merge, the head was updated. Hint: Try again.
|
||||
pulls.push_rejected = Merge Failed: The push was rejected. Review the githooks for this repository.
|
||||
pulls.push_rejected = Merge Failed: The push was rejected. Review the Git Hooks for this repository.
|
||||
pulls.push_rejected_summary = Full Rejection Message
|
||||
pulls.push_rejected_no_message = Merge Failed: The push was rejected but there was no remote message.<br>Review the githooks for this repository
|
||||
pulls.push_rejected_no_message = Merge Failed: The push was rejected but there was no remote message.<br>Review the Git Hooks for this repository
|
||||
pulls.open_unmerged_pull_exists = `You cannot perform a reopen operation because there is a pending pull request (#%d) with identical properties.`
|
||||
pulls.status_checking = Some checks are pending
|
||||
pulls.status_checks_success = All checks were successful
|
||||
|
|
@ -1834,7 +1834,7 @@ settings.webhook.response = Response
|
|||
settings.webhook.headers = Headers
|
||||
settings.webhook.payload = Content
|
||||
settings.webhook.body = Body
|
||||
settings.githooks_desc = "Git hooks are powered by Git itself. You can edit hook files below to set up custom operations."
|
||||
settings.githooks_desc = "Git Hooks are powered by Git itself. You can edit hook files below to set up custom operations."
|
||||
settings.githook_edit_desc = If the hook is inactive, sample content will be presented. Leaving content to an empty value will disable this hook.
|
||||
settings.githook_name = Hook Name
|
||||
settings.githook_content = Hook Content
|
||||
|
|
|
|||
Loading…
Reference in a new issue