msgstr "linkgit:gittutorial[7], linkgit:gittutorial-2[7], linkgit:gitcvs-migration[7], linkgit:giteveryday[7], link:user-manual.html[Hướng dẫn sử dụng Git]"
msgid "Append ref names and object names of fetched refs to the existing contents of `.git/FETCH_HEAD`. Without this option old data in `.git/FETCH_HEAD` will be overwritten."
msgid "Limit fetching to the specified number of commits from the tip of each remote branch history. If fetching to a 'shallow' repository created by `git clone` with `--depth=<depth>` option (see linkgit:git-clone[1]), deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched."
msgid "Similar to --depth, except it specifies the number of commits from the current shallow boundary instead of from the tip of each remote branch history."
msgid "Deepen or shorten the history of a shallow repository to exclude commits reachable from a specified remote branch or tag. This option can be specified multiple times."
msgid "If the source repository is complete, convert a shallow repository to a complete one, removing all the limitations imposed by shallow repositories."
msgstr ""
msgstr "如果源仓库是完整的，将浅层资源库转换为完整的仓库，消除浅层仓库带来的所有限制。"
#. type: Plain text
#: en/fetch-options.txt:42
#, priority:220
msgid "If the source repository is shallow, fetch as much as possible so that the current repository has the same history as the source repository."
msgstr ""
msgstr "如果源仓库是浅层的，尽可能多的获取，使当前仓库的历史与源仓库相同。"
#. type: Labeled list
#: en/fetch-options.txt:43
...
...
@@ -5940,7 +5940,7 @@ msgstr "--update-shallow"
#: en/fetch-options.txt:48
#, priority:220
msgid "By default when fetching from a shallow repository, `git fetch` refuses refs that require updating .git/shallow. This option updates .git/shallow and accept such refs."
msgid "By default, Git will report, to the server, commits reachable from all local refs to find common commits in an attempt to reduce the size of the to-be-received packfile. If specified, Git will only report commits reachable from the given tips. This is useful to speed up fetches when the user knows which local ref is likely to have commits in common with the upstream ref being fetched."
msgid "This option may be specified more than once; if so, Git will report commits reachable from any of the given commits."
msgstr ""
msgstr "这个选项可以指定多次；如果是这样，Git将报告从任何一个给定的提交中可达提交。"
#. type: Plain text
#: en/fetch-options.txt:64
#, priority:220
msgid "The argument to this option may be a glob on ref names, a ref, or the (possibly abbreviated) SHA-1 of a commit. Specifying a glob is equivalent to specifying this option multiple times, one for each matching ref name."
msgid "See also the `fetch.negotiationAlgorithm` and `push.negotiate` configuration variables documented in linkgit:git-config[1], and the `--negotiate-only` option below."
msgid "This is incompatible with `--recurse-submodules=[yes|on-demand]`. Internally this is used to implement the `push.negotiate` option, see linkgit:git-config[1]."
msgid "Write the list of remote refs fetched in the `FETCH_HEAD` file directly under `$GIT_DIR`. This is the default. Passing `--no-write-fetch-head` from the command line tells Git not to write the file. Under `--dry-run` option, the file is never written."
msgid "With `add`, create a new branch named `<new-branch>` starting at `<commit-ish>`, and check out `<new-branch>` into the new worktree. If `<commit-ish>` is omitted, it defaults to `HEAD`. By default, `-b` refuses to create a new branch if it already exists. `-B` overrides this safeguard, resetting `<new-branch>` to `<commit-ish>`."
msgid "By default, `add` checks out `<commit-ish>`, however, `--no-checkout` can be used to suppress checkout in order to make customizations, such as configuring sparse-checkout. See \"Sparse checkout\" in linkgit:git-read-tree[1]."
msgid "With `worktree add <path>`, without `<commit-ish>`, instead of creating a new branch from `HEAD`, if there exists a tracking branch in exactly one remote matching the basename of `<path>`, base the new branch on the remote-tracking branch, and mark the remote-tracking branch as \"upstream\" from the new branch."
msgid "When creating a new branch, if `<commit-ish>` is a branch, mark it as \"upstream\" from the new branch. This is the default if `<commit-ish>` is a remote-tracking branch. See `--track` in linkgit:git-branch[1] for details."
msgid "Terminate each line with a NUL rather than a newline when `--porcelain` is specified with `list`. This makes it possible to parse the output when a worktree path contains a newline character."
msgid "With `lock` or with `add --lock`, an explanation why the worktree is locked."
msgstr ""
msgstr "用`lock`或用`add --lock`，解释为什么工作区被锁定。"
#. type: Labeled list
#: en/git-worktree.txt:257
...
...
@@ -61570,13 +61570,13 @@ msgstr "<worktree>"
#: en/git-worktree.txt:259
#, priority:240
msgid "Worktrees can be identified by path, either relative or absolute."
msgstr ""
msgstr "工作区可以通过相对或绝对路径来识别。"
#. type: Plain text
#: en/git-worktree.txt:264
#, priority:240
msgid "If the last path components in the worktree's path is unique among worktrees, it can be used to identify a worktree. For example if you only have two worktrees, at `/abc/def/ghi` and `/abc/def/ggg`, then `ghi` or `def/ghi` is enough to point to the former worktree."
msgid "When using multiple worktrees, some refs are shared between all worktrees, but others are specific to an individual worktree. One example is `HEAD`, which is different for each worktree. This section is about the sharing rules and how to access refs of one worktree from another."
msgid "In general, all pseudo refs are per-worktree and all refs starting with `refs/` are shared. Pseudo refs are ones like `HEAD` which are directly under `$GIT_DIR` instead of inside `$GIT_DIR/refs`. There are exceptions, however: refs inside `refs/bisect` and `refs/worktree` are not shared."
msgid "Refs that are per-worktree can still be accessed from another worktree via two special paths, `main-worktree` and `worktrees`. The former gives access to per-worktree refs of the main worktree, while the latter to all linked worktrees."
msgid "For example, `main-worktree/HEAD` or `main-worktree/refs/bisect/good` resolve to the same value as the main worktree's `HEAD` and `refs/bisect/good` respectively. Similarly, `worktrees/foo/HEAD` or `worktrees/bar/refs/bisect/bad` are the same as `$GIT_COMMON_DIR/worktrees/foo/HEAD` and `$GIT_COMMON_DIR/worktrees/bar/refs/bisect/bad`."
msgid "To access refs, it's best not to look inside `$GIT_DIR` directly. Instead use commands such as linkgit:git-rev-parse[1] or linkgit:git-update-ref[1] which will handle refs correctly."
msgid "By default, the repository `config` file is shared across all worktrees. If the config variables `core.bare` or `core.worktree` are present in the common config file and `extensions.worktreeConfig` is disabled, then they will be applied to the main worktree only."
msgid "In this mode, specific configuration stays in the path pointed by `git rev-parse --git-path config.worktree`. You can add or update configuration in this file with `git config --worktree`. Older Git versions will refuse to access repositories with this extension."
msgid "Note that in this file, the exception for `core.bare` and `core.worktree` is gone. If they exist in `$GIT_DIR/config`, you must move them to the `config.worktree` of the main worktree. You may also take this opportunity to review and move other configuration that you do not want to share to all worktrees:"
msgid "Each linked worktree has a private sub-directory in the repository's `$GIT_DIR/worktrees` directory. The private sub-directory's name is usually the base name of the linked worktree's path, possibly appended with a number to make it unique. For example, when `$GIT_DIR=/path/main/.git` the command `git worktree add /path/other/test-next next` creates the linked worktree in `/path/other/test-next` and also creates a `$GIT_DIR/worktrees/test-next` directory (or `$GIT_DIR/worktrees/test-next1` if `test-next` is already taken)."
msgid "Within a linked worktree, `$GIT_DIR` is set to point to this private directory (e.g. `/path/main/.git/worktrees/test-next` in the example) and `$GIT_COMMON_DIR` is set to point back to the main worktree's `$GIT_DIR` (e.g. `/path/main/.git`). These settings are made in a `.git` file located at the top directory of the linked worktree."
msgid "Path resolution via `git rev-parse --git-path` uses either `$GIT_DIR` or `$GIT_COMMON_DIR` depending on the path. For example, in the linked worktree `git rev-parse --git-path HEAD` returns `/path/main/.git/worktrees/test-next/HEAD` (not `/path/other/test-next/.git/HEAD` or `/path/main/.git/HEAD`) while `git rev-parse --git-path refs/heads/master` uses `$GIT_COMMON_DIR` and returns `/path/main/.git/refs/heads/master`, since refs are shared across all worktrees, except `refs/bisect` and `refs/worktree`."
msgid "See linkgit:gitrepository-layout[5] for more information. The rule of thumb is do not make any assumption about whether a path belongs to `$GIT_DIR` or `$GIT_COMMON_DIR` when you need to directly access something inside `$GIT_DIR`. Use `git rev-parse --git-path` to get the final path."
msgid "If you manually move a linked worktree, you need to update the `gitdir` file in the entry's directory. For example, if a linked worktree is moved to `/newpath/test-next` and its `.git` file points to `/path/main/.git/worktrees/test-next`, then update `/path/main/.git/worktrees/test-next/gitdir` to reference `/newpath/test-next` instead. Better yet, run `git worktree repair` to reestablish the connection automatically."
msgid "To prevent a `$GIT_DIR/worktrees` entry from being pruned (which can be useful in some situations, such as when the entry's worktree is stored on a portable device), use the `git worktree lock` command, which adds a file named `locked` to the entry's directory. The file contains the reason in plain text. For example, if a linked worktree's `.git` file points to `/path/main/.git/worktrees/test-next` then a file named `/path/main/.git/worktrees/test-next/locked` will prevent the `test-next` entry from being pruned. See linkgit:gitrepository-layout[5] for details."
msgid "For these annotations, a reason might also be available and this can be seen using the verbose mode. The annotation is then moved to the next line indented followed by the additional information."
msgid "Note that the annotation is moved to the next line if the additional information is available, otherwise it stays on the same line as the worktree itself."
msgstr ""
msgstr "注意，如果有额外的信息，注释将被移到下一行，否则它将与工作区本身保持在同一行。"
#. type: Title ~
#: en/git-worktree.txt:426
#, no-wrap, priority:240
msgid "Porcelain Format"
msgstr ""
msgstr "上层命令格式"
#. type: Plain text
#: en/git-worktree.txt:435
#, priority:240
msgid "The porcelain format has a line per attribute. If `-z` is given then the lines are terminated with NUL rather than a newline. Attributes are listed with a label and value separated by a single space. Boolean attributes (like `bare` and `detached`) are listed as a label only, and are present only if the value is true. Some attributes (like `locked`) can be listed as a label only or with a value depending upon whether a reason is available. The first attribute of a worktree is always `worktree`, an empty line indicates the end of the record. For example:"
"prunable gitdir file points to non-existent location\n"
msgstr ""
"worktree /path/to/linked-worktree-prunable\n"
"HEAD 1233def1234def1234def1234def1234def1234b\n"
"detached\n"
"修剪的gitdir文件指向不存在的位置\n"
#. type: Plain text
#: en/git-worktree.txt:470
#, fuzzy, priority:240
#, priority:240
msgid "Unless `-z` is used any \"unusual\" characters in the lock reason such as newlines are escaped and the entire reason is quoted as explained for the configuration variable `core.quotePath` (see linkgit:git-config[1]). For Example:"
msgid "You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use linkgit:git-stash[1] to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don't want to risk disturbing any of it. Instead, you create a temporary linked worktree to make the emergency fix, remove it when done, and then resume your earlier refactoring session."
msgid "Multiple checkout in general is still experimental, and the support for submodules is incomplete. It is NOT recommended to make multiple checkouts of a superproject."
msgid "With --no-commit perform the merge and stop just before creating a merge commit, to give the user a chance to inspect and further tweak the merge result before committing."
msgid "Note that fast-forward updates do not create a merge commit and therefore there is no way to stop those merges with --no-commit. Thus, if you want to ensure your branch is not changed or updated by the merge command, use --no-ff with --no-commit."
msgid "Invoke an editor before committing successful mechanical merge to further edit the auto-generated merge message, so that the user can explain and justify the merge. The `--no-edit` option can be used to accept the auto-generated message (this is generally discouraged)."
msgid "The `--edit` (or `-e`) option is still useful if you are giving a draft message with the `-m` option from the command line and want to edit it in the editor."
msgid "Older scripts may depend on the historical behaviour of not allowing the user to edit the merge log message. They will see an editor opened when they run `git merge`. To make it easier to adjust such scripts to the updated behaviour, the environment variable `GIT_MERGE_AUTOEDIT` can be set to `no` at the beginning of them."
msgid "This option determines how the merge message will be cleaned up before committing. See linkgit:git-commit[1] for more details. In addition, if the '<mode>' is given a value of `scissors`, scissors will be appended to `MERGE_MSG` before being passed on to the commit machinery in the case of a merge conflict."
msgid "Specifies how a merge is handled when the merged-in history is already a descendant of the current history. `--ff` is the default unless merging an annotated (and possibly signed) tag that is not stored in its natural place in the `refs/tags/` hierarchy, in which case `--no-ff` is assumed."
msgid "Only update to the new history if there is no divergent local history. This is the default when no method for reconciling divergent histories is provided (via the --rebase=* flags)."
msgid "When merging rather than rebasing, specifies how a merge is handled when the merged-in history is already a descendant of the current history. If merging is requested, `--ff` is the default unless merging an annotated (and possibly signed) tag that is not stored in its natural place in the `refs/tags/` hierarchy, in which case `--no-ff` is assumed."
msgid "With `--ff`, when possible resolve the merge as a fast-forward (only update the branch pointer to match the merged branch; do not create a merge commit). When not possible (when the merged-in history is not a descendant of the current history), create a merge commit."
msgid "GPG-sign the resulting merge commit. The `keyid` argument is optional and defaults to the committer identity; if specified, it must be stuck to the option without a space. `--no-gpg-sign` is useful to countermand both `commit.gpgSign` configuration variable, and earlier `--gpg-sign`."
msgid "In addition to branch names, populate the log message with one-line descriptions from at most <n> actual commits that are being merged. See also linkgit:git-fmt-merge-msg[1]."
msgid "With --no-log do not list one-line descriptions from the actual commits being merged."
msgstr ""
msgstr "如果使用 --no-log，则不列出被合并的实际提交内容的单行描述。"
#. type: Plain text
#: en/merge-options.txt:112
#, priority:240
msgid "Show a diffstat at the end of the merge. The diffstat is also controlled by the configuration option merge.stat."
msgstr ""
msgstr "在合并结束时显示一个差异状态。差异状态也由配置选项merge.stat控制。"
#. type: Plain text
#: en/merge-options.txt:115
#, priority:240
msgid "With -n or --no-stat do not show a diffstat at the end of the merge."
msgstr ""
msgstr "使用-n或--no-stat，在合并结束时不显示差异状态。"
#. type: Labeled list
#: en/merge-options.txt:116
...
...
@@ -63573,49 +63597,49 @@ msgstr "--no-squash"
#: en/merge-options.txt:125
#, priority:240
msgid "Produce the working tree and index state as if a real merge happened (except for the merge information), but do not actually make a commit, move the `HEAD`, or record `$GIT_DIR/MERGE_HEAD` (to cause the next `git commit` command to create a merge commit). This allows you to create a single commit on top of the current branch whose effect is the same as merging another branch (or more in case of an octopus)."
msgid "Use the given merge strategy; can be supplied more than once to specify them in the order they should be tried. If there is no `-s` option, a built-in list of strategies is used instead (`ort` when merging a single head, `octopus` otherwise)."
msgid "Verify that the tip commit of the side branch being merged is signed with a valid key, i.e. a key that has a valid uid: in the default trust model, this means the signing key has been signed by a trusted key. If the tip commit of the side branch is not signed with a valid key, the merge is aborted."
msgid "Synonyms to --stat and --no-stat; these are deprecated and will be removed in the future."
msgstr ""
msgstr "与 --stat 和 --no-stat 同义；这些都弃用了，将来会被删除。"
#. type: Plain text
#: en/merge-options.txt:177
#, priority:240
msgid "Operate quietly. Implies --no-progress."
msgstr ""
msgstr "安静地操作。暗指 --no-progress。"
#. type: Plain text
#: en/merge-options.txt:188
#, priority:240
msgid "Turn progress on/off explicitly. If neither is specified, progress is shown if standard error is connected to a terminal. Note that not all merge strategies may support progress reporting."
msgid "By default, `git merge` command refuses to merge histories that do not share a common ancestor. This option can be used to override this safety when merging histories of two projects that started their lives independently. As that is a very rare occasion, no configuration variable to enable this by default exists and will not be added."
msgid "The merge mechanism (`git merge` and `git pull` commands) allows the backend 'merge strategies' to be chosen with `-s` option. Some strategies can also take their own options, which can be passed by giving `-X<option>` arguments to `git merge` and/or `git pull`."
msgid "This is the default merge strategy when pulling or merging one branch. This strategy can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this strategy can detect and handle merges involving renames. It does not make use of detected copies. The name for this algorithm is an acronym (\"Ostensibly Recursive's Twin\") and came from the fact that it was written as a replacement for the previous default algorithm, `recursive`."
msgid "This option forces conflicting hunks to be auto-resolved cleanly by favoring 'our' version. Changes from the other tree that do not conflict with our side are reflected in the merge result. For a binary file, the entire contents are taken from our side."
msgid "This should not be confused with the 'ours' merge strategy, which does not even look at what the other tree contains at all. It discards everything the other tree did, declaring 'our' history contains all that happened in it."
msgid "Treats lines with the indicated type of whitespace change as unchanged for the sake of a three-way merge. Whitespace changes mixed with other changes to a line are not ignored. See also linkgit:git-diff[1] `-b`, `-w`, `--ignore-space-at-eol`, and `--ignore-cr-at-eol`."
msgid "Otherwise, the merge proceeds in the usual way."
msgstr ""
msgstr "否则，合并将以常规方式进行。"
#. type: Labeled list
#: en/merge-strategies.txt:57
...
...
@@ -63772,7 +63796,7 @@ msgstr "renormalize"
#: en/merge-strategies.txt:64
#, priority:240
msgid "This runs a virtual check-out and check-in of all three stages of a file when resolving a three-way merge. This option is meant to be used when merging branches with different clean filters or end-of-line normalization rules. See \"Merging branches with differing checkin/checkout attributes\" in linkgit:gitattributes[5] for details."
msgid "Turn on rename detection, optionally setting the similarity threshold. This is the default. This overrides the 'merge.renames' configuration variable. See also linkgit:git-diff[1] `--find-renames`."
msgid "Deprecated synonym for `find-renames=<n>`."
msgstr ""
msgstr "废弃的，`find-renames=<n>` 的同义词。"
#. type: Labeled list
#: en/merge-strategies.txt:78
#, no-wrap, priority:240
msgid "subtree[=<path>]"
msgstr ""
msgstr "subtree[=<路径>]"
#. type: Plain text
#: en/merge-strategies.txt:84
#, priority:240
msgid "This option is a more advanced form of 'subtree' strategy, where the strategy makes a guess on how two trees must be shifted to match with each other when merging. Instead, the specified path is prefixed (or stripped from the beginning) to make the shape of two trees to match."
msgid "This can only resolve two heads using a 3-way merge algorithm. When there is more than one common ancestor that can be used for 3-way merge, it creates a merged tree of the common ancestors and uses that as the reference tree for the 3-way merge. This has been reported to result in fewer merge conflicts without causing mismerges by tests done on actual merge commits taken from Linux 2.6 kernel development history. Additionally this can detect and handle merges involving renames. It does not make use of detected copies. This was the default strategy for resolving two heads from Git v0.99.9k until v2.33.0."
msgid "The 'recursive' strategy takes the same options as 'ort'. However, there are three additional options that 'ort' ignores (not documented above) that are potentially useful with the 'recursive' strategy:"
msgid "Use a different diff algorithm while merging, which can help avoid mismerges that occur due to unimportant matching lines (such as braces from distinct functions). See also linkgit:git-diff[1] `--diff-algorithm`. Note that `ort` specifically uses `diff-algorithm=histogram`, while `recursive` defaults to the `diff.algorithm` config setting."
msgid "This can only resolve two heads (i.e. the current branch and another branch you pulled from) using a 3-way merge algorithm. It tries to carefully detect criss-cross merge ambiguities. It does not handle renames."
msgid "This resolves cases with more than two heads, but refuses to do a complex merge that needs manual resolution. It is primarily meant to be used for bundling topic branch heads together. This is the default merge strategy when pulling or merging more than one branch."
msgid "This resolves any number of heads, but the resulting tree of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. It is meant to be used to supersede old development history of side branches. Note that this is different from the -Xours option to the 'recursive' merge strategy."
msgid "This is a modified `ort` strategy. When merging trees A and B, if B corresponds to a subtree of A, B is first adjusted to match the tree structure of A, instead of reading the trees at the same level. This adjustment is also done to the common ancestor tree."
msgid "With the strategies that use 3-way merge (including the default, 'ort'), if a change is made on both branches, but later reverted on one of the branches, that change will be present in the merged result; some people find this behavior confusing. It occurs because only the heads and the merge base are considered when performing a merge, not the individual commits. The merge algorithm therefore considers the reverted change as no change at all, and substitutes the changed version instead."
msgid "After the rerere mechanism reuses a recorded resolution on the current conflict to update the files in the working tree, allow it to also update the index with the result of resolution. `--no-rerere-autoupdate` is a good way to double-check what `rerere` did and catch potential mismerges, before committing the result to the index with a separate `git add`."
