Translated using Weblate (Chinese (Simplified))

Currently translated at 69.6% (7790 of 11184 strings)

Translation: Git Manpages/Translations
Translate-URL: https://hosted.weblate.org/projects/git-manpages/translations/zh_Hans/


Signed-off-by: 秃头灯笼鱼 <ttdlyu@163.com>

po/documentation.zh_HANS-CN.po

@@ -3,19 +3,7 @@
 # This file is distributed under the same license as the Git package.
 # Matthias Aßhauer <mha1993@live.de>, 2019.
 msgid ""
-msgstr ""
-"Project-Id-Version: git documentation\n"
-"Report-Msgid-Bugs-To: jn.avila@free.fr\n"
-"POT-Creation-Date: 2023-11-04 20:14+0100\n"
-"PO-Revision-Date: 2023-11-04 17:49+0000\n"
-"Last-Translator: 秃头灯笼鱼 <ttdlyu@163.com>\n"
-"Language-Team: LANGUAGE <LL@li.org>\n"
-"Language: zh_HANS-CN\n"
-"MIME-Version: 1.0\n"
-"Content-Type: text/plain; charset=UTF-8\n"
-"Content-Transfer-Encoding: 8bit\n"
-"Plural-Forms: nplurals=1; plural=0;\n"
-"X-Generator: Weblate 5.2-dev\n"
+msgstr "Project-Id-Version: git documentation\nReport-Msgid-Bugs-To: jn.avila@free.fr\nPOT-Creation-Date: 2023-11-04 20:14+0100\nPO-Revision-Date: 2023-11-11 01:34+0000\nLast-Translator: 秃头灯笼鱼 <ttdlyu@163.com>\nLanguage-Team: LANGUAGE <LL@li.org>\nLanguage: zh_HANS-CN\nMIME-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: 8bit\nPlural-Forms: nplurals=1; plural=0;\nX-Generator: Weblate 5.2-dev\n"
 #. type: Labeled list
 #: en/blame-options.txt:1 en/diff-options.txt:780 en/git-instaweb.txt:45 en/git-mailinfo.txt:49 en/git-mailsplit.txt:35 en/git-repack.txt:180 en/git-status.txt:31
@@ -1616,8 +1604,8 @@ msgstr "尽可能找到好的共同祖先进行合并。"
 msgid "linkgit:git-name-rev[1]"
 msgstr "linkgit:git-name-rev[1]"
-#. type: Plain text
 # 查找给定版本的符号名称
+#. type: Plain text
 #: en/cmds-plumbinginterrogators.txt:39
 #, priority:100
 msgid "Find symbolic names for given revs."
@@ -4089,7 +4077,7 @@ msgstr "-m"
 #: en/diff-options.txt:44
 #, priority:280
 msgid "Show diffs for merge commits in the default format. This is similar to '--diff-merges=on', except `-m` will produce no output unless `-p` is given as well."
-msgstr ""
+msgstr "以默认格式显示合并提交的差异。这与 '--diff-merges=on' 类似，但除非同时给出 `-p`，否则 `-m` 不会产生任何输出。"
 #. type: Labeled list
 #: en/diff-options.txt:45 en/git-am.txt:57 en/git-blame.txt:53 en/git-branch.txt:138 en/git-cvsexportcommit.txt:37 en/git-diff-files.txt:37 en/git-diff-tree.txt:93 en/git-grep.txt:188 en/git-help.txt:65 en/git-ls-files.txt:38 en/git-shortlog.txt:87 en/git-stripspace.txt:42
@@ -4101,7 +4089,7 @@ msgstr "-c"
 #: en/diff-options.txt:48
 #, priority:280
 msgid "Produce combined diff output for merge commits.  Shortcut for '--diff-merges=combined -p'."
-msgstr ""
+msgstr "生成合并提交的合并差异输出。 '--diff-merges=combined -p' 的快捷方式。"
 #. type: Labeled list
 #: en/diff-options.txt:49 en/git-diff-files.txt:38 en/git-diff-tree.txt:103
@@ -4113,7 +4101,7 @@ msgstr "--cc"
 #: en/diff-options.txt:52
 #, priority:280
 msgid "Produce dense combined diff output for merge commits.  Shortcut for '--diff-merges=dense-combined -p'."
-msgstr ""
+msgstr "生成合并提交的密集合并差异输出。 '--diff-merges=dense-combined -p' 的快捷方式。"
 #. type: Labeled list
 #: en/diff-options.txt:53
@@ -4125,7 +4113,7 @@ msgstr "--dd"
 #: en/diff-options.txt:57
 #, priority:280
 msgid "Produce diff with respect to first parent for both merge and regular commits.  Shortcut for '--diff-merges=first-parent -p'."
-msgstr ""
+msgstr "为合并提交和常规提交生成与第一父提交的差异。 '--diff-merges=first-parent -p' 的快捷方式。"
 #. type: Labeled list
 #: en/diff-options.txt:58
@@ -4137,7 +4125,7 @@ msgstr "--remerge-diff"
 #: en/diff-options.txt:61
 #, priority:280
 msgid "Produce remerge-diff output for merge commits.  Shortcut for '--diff-merges=remerge -p'."
-msgstr ""
+msgstr "生成合并提交的 remerge-diff 输出。 '--diff-merges=remerge -p' 的快捷方式。"
 #. type: Labeled list
 #: en/diff-options.txt:62
@@ -4209,7 +4197,7 @@ msgstr "--first-parent"
 #: en/diff-options.txt:86
 #, priority:280
 msgid "Show full diff with respect to first parent. This is the same format as `--patch` produces for non-merge commits."
-msgstr ""
+msgstr "显示与第一个父提交的完整差异。这与 `--patch` 为非合并提交生成的格式相同。"
 #. type: Labeled list
 #: en/diff-options.txt:87
@@ -7196,8 +7184,8 @@ msgstr "删除的内容"
 msgid "Removed content is represented by lines beginning with \"-\". You can prevent staging their removal by converting the \"-\" to a \" \" (space)."
 msgstr "删除的内容以“-”开头的行表示。您可以通过将“-”转换为“ ”（空格）来防止将其删除。"
-#. type: Labeled list
 # 译者：末尾两个字节可能被删减，如果翻译为中文标点会出现半个汉字
+#. type: Labeled list
 #: en/git-add.txt:388
 #, no-wrap, priority:300
 msgid "modified content"
@@ -9283,7 +9271,7 @@ msgstr "$ git bisect visualize\n"
 #: en/git-bisect.txt:212
 #, priority:100
 msgid "Git detects a graphical environment through various environment variables: `DISPLAY`, which is set in X Window System environments on Unix systems.  `SESSIONNAME`, which is set under Cygwin in interactive desktop sessions.  `MSYSTEM`, which is set under Msys2 and Git for Windows.  `SECURITYSESSIONID`, which may be set on macOS in interactive desktop sessions."
-msgstr ""
+msgstr "Git 通过各种环境变量检测图形环境：`DISPLAY`，在 Unix 系统的 X 窗口系统环境中设置。 `SESSIONNAME` （会话名），在 Cygwin 下的交互式桌面会话中设置。 `MSYSTEM`，在 Msys2 和 Git for Windows 下设置。 `SECURITYSESSIONID`，可在 macOS 上的交互式桌面会话中设置。"
 #. type: Plain text
 #: en/git-bisect.txt:215
@@ -26196,7 +26184,7 @@ msgstr "假设您想从所有提交中删除一个文件（包含机密信息或
 #: en/git-filter-branch.txt:254
 #, no-wrap, priority:90
 msgid "git filter-branch --tree-filter 'rm filename' HEAD\n"
-msgstr ""
+msgstr "git filter-branch --tree-filter 'rm filename' HEAD\n"
 #. type: Plain text
 #: en/git-filter-branch.txt:259
@@ -26522,49 +26510,49 @@ msgstr "git-filter-branch 可以用来去掉一部分文件，通常与 `--index
 #: en/git-filter-branch.txt:435
 #, priority:90
 msgid "You really removed all variants of a filename, if a blob was moved over its lifetime.  `git log --name-only --follow --all -- filename` can help you find renames."
-msgstr ""
+msgstr "如果一个 blob 在其生命周期内被移动过，你就真的删除了文件名的所有变体。 `git log --name-only --follow --all -- filename` 可以帮你找到重命名。"
 #. type: Plain text
 #: en/git-filter-branch.txt:438
 #, priority:90
 msgid "You really filtered all refs: use `--tag-name-filter cat -- --all` when calling git-filter-branch."
-msgstr ""
+msgstr "你真的过滤了所有引用：在调用 git-filter-branch 时使用 `--tag-name-filter cat ----all` 。"
 #. type: Plain text
 #: en/git-filter-branch.txt:441
 #, priority:90
 msgid "Then there are two ways to get a smaller repository.  A safer way is to clone, that keeps your original intact."
-msgstr ""
+msgstr "那么有两种方法可以获得更小的仓库。 比较安全的方法是克隆，这样可以保持你的原始版本不变。"
 #. type: Plain text
 #: en/git-filter-branch.txt:445
 #, priority:90
 msgid "Clone it with `git clone file:///path/to/repo`.  The clone will not have the removed objects.  See linkgit:git-clone[1].  (Note that cloning with a plain path just hardlinks everything!)"
-msgstr ""
+msgstr "使用 `git clone file:///path/to/repo` 克隆它。 克隆后将不会有被删除的对象。 参见 linkgit:git-clone[1]。 (注意，用纯路径克隆只会硬链接一切！）"
 #. type: Plain text
 #: en/git-filter-branch.txt:450
 #, priority:90
 msgid "If you really don't want to clone it, for whatever reasons, check the following points instead (in this order).  This is a very destructive approach, so *make a backup* or go back to cloning it.  You have been warned."
-msgstr ""
+msgstr "如果你真的不想克隆它，不管出于什么原因，请检查以下几点（按此顺序）。 这是一种破坏性很强的方法，所以 *做好备份*，或者重新克隆。 我已经警告过你了。"
 #. type: Plain text
 #: en/git-filter-branch.txt:454
 #, priority:90
 msgid "Remove the original refs backed up by git-filter-branch: say `git for-each-ref --format=\"%(refname)\" refs/original/ | xargs -n 1 git update-ref -d`."
-msgstr ""
+msgstr "删除由 git-filter-branch 支持的原始参考文件：说 `git for-each-ref --format=\"%(引用名称)\" refs/original/ | xargs -n 1 git update-ref -d`."
 #. type: Plain text
 #: en/git-filter-branch.txt:456
 #, priority:90
 msgid "Expire all reflogs with `git reflog expire --expire=now --all`."
-msgstr ""
+msgstr "使用 `git reflog expire --expire=now --all` 过期所有引用日志。"
 #. type: Plain text
 #: en/git-filter-branch.txt:460
 #, priority:90
 msgid "Garbage collect all unreferenced objects with `git gc --prune=now` (or if your git-gc is not new enough to support arguments to `--prune`, use `git repack -ad; git prune` instead)."
-msgstr ""
+msgstr "使用 `git gc --prune=now` 清理所有未引用的对象（如果你的 git-gc 还不够新，不支持 `--prune` 的参数，则使用 `git repack -ad; git prune` 代替）。"
 #. type: Plain text
 #: en/git-filter-branch.txt:467
@@ -26576,43 +26564,43 @@ msgstr "The performance of git-filter-branch is glacially slow; its design makes
 #: en/git-filter-branch.txt:473
 #, priority:90
 msgid "In editing files, git-filter-branch by design checks out each and every commit as it existed in the original repo.  If your repo has `10^5` files and `10^5` commits, but each commit only modifies five files, then git-filter-branch will make you do `10^10` modifications, despite only having (at most) `5*10^5` unique blobs."
-msgstr ""
+msgstr "在编辑文件时，git-filter-branch 会检查原始仓库中的每个提交。 如果你的仓库有 `10^5` 个文件和 `10^5` 次提交，但每次提交只修改了五个文件，那么 git-filter-branch 会让你做 `10^10` 次修改，尽管（最多）只有 `5*10^5` 个唯一的 blob。"
 #. type: Plain text
 #: en/git-filter-branch.txt:476
 #, priority:90
 msgid "If you try and cheat and try to make git-filter-branch only work on files modified in a commit, then two things happen"
-msgstr ""
+msgstr "如果你试图作弊，让 git-filter-branch 只对提交中修改过的文件起作用，那么会发生两种情况"
 #. type: Plain text
 #: en/git-filter-branch.txt:482
 #, priority:90
 msgid "you run into problems with deletions whenever the user is simply trying to rename files (because attempting to delete files that don't exist looks like a no-op; it takes some chicanery to remap deletes across file renames when the renames happen via arbitrary user-provided shell)"
-msgstr ""
+msgstr "当用户只是试图重命名文件时，就会遇到删除问题（因为试图删除不存在的文件看起来是不可能的；当重命名通过任意用户提供的 shell 进行时，需要一些技巧来重新映射文件重命名时的删除）"
 #. type: Plain text
 #: en/git-filter-branch.txt:488
 #, priority:90
 msgid "even if you succeed at the map-deletes-for-renames chicanery, you still technically violate backward compatibility because users are allowed to filter files in ways that depend upon topology of commits instead of filtering solely based on file contents or names (though this has not been observed in the wild)."
-msgstr ""
+msgstr "即使你成功地使用了 map-deletes-for-renames 的诡计，从技术上讲，你仍然违反了向后兼容性，因为用户可以根据提交的拓扑结构来过滤文件，而不是仅仅根据文件内容或名称来过滤（尽管在实际中还没有观察到这种情况）。"
 #. type: Plain text
 #: en/git-filter-branch.txt:495
 #, priority:90
 msgid "Even if you don't need to edit files but only want to e.g. rename or remove some and thus can avoid checking out each file (i.e. you can use --index-filter), you still are passing shell snippets for your filters.  This means that for every commit, you have to have a prepared git repo where those filters can be run.  That's a significant setup."
-msgstr ""
+msgstr "即使您不需要编辑文件，而只想重命名或删除某些文件，从而可以避免检查每个文件（即您可以使用 --index-filter ），您仍然要为过滤器传递 shell 片段。 这意味着每次提交时，您都必须准备一个可以运行这些过滤器的 git repo。 这可是个大工程。"
 #. type: Plain text
 #: en/git-filter-branch.txt:507
 #, priority:90
 msgid "Further, several additional files are created or updated per commit by git-filter-branch.  Some of these are for supporting the convenience functions provided by git-filter-branch (such as map()), while others are for keeping track of internal state (but could have also been accessed by user filters; one of git-filter-branch's regression tests does so).  This essentially amounts to using the filesystem as an IPC mechanism between git-filter-branch and the user-provided filters.  Disks tend to be a slow IPC mechanism, and writing these files also effectively represents a forced synchronization point between separate processes that we hit with every commit."
-msgstr ""
+msgstr "此外，git-filter-branch 还会在每次提交时创建或更新几个额外的文件。 其中一些用于支持 git-filter-branch 提供的便利函数（如 map()），另一些则用于跟踪内部状态（但也可能被用户过滤器访问；git-filter-branch 的一个回归测试就是这么做的）。 这基本上相当于把文件系统用作 git-filter-branch 和用户提供的过滤器之间的 IPC 机制。 磁盘往往是一种缓慢的 IPC 机制，而写入这些文件实际上也代表了我们在每次提交时都要在不同进程间强制同步的点。"
 #. type: Plain text
 #: en/git-filter-branch.txt:513
 #, priority:90
 msgid "The user-provided shell commands will likely involve a pipeline of commands, resulting in the creation of many processes per commit.  Creating and running another process takes a widely varying amount of time between operating systems, but on any platform it is very slow relative to invoking a function."
-msgstr ""
+msgstr "用户提供的 shell 命令很可能涉及命令流水线，导致每次提交都要创建许多进程。 在不同的操作系统上，创建和运行另一个进程所需的时间差别很大，但在任何平台上，相对于调用一个函数而言，创建和运行另一个进程都是非常缓慢的。"
 #. type: Plain text
 #: en/git-filter-branch.txt:519
@@ -26624,13 +26612,13 @@ msgstr "git-filter-branch itself is written in shell, which is kind of slow.  Th
 #: en/git-filter-branch.txt:530
 #, priority:90
 msgid "Side note: Unfortunately, people tend to fixate on the written-in-shell aspect and periodically ask if git-filter-branch could be rewritten in another language to fix the performance issues.  Not only does that ignore the bigger intrinsic problems with the design, it'd help less than you'd expect: if git-filter-branch itself were not shell, then the convenience functions (map(), skip_commit(), etc) and the `--setup` argument could no longer be executed once at the beginning of the program but would instead need to be prepended to every user filter (and thus re-executed with every commit)."
-msgstr ""
+msgstr "题外话：不幸的是，人们往往会把注意力集中在用 shell 编写的问题上，并定期询问是否可以用其他语言重写 git-filter-branch，以解决性能问题。 如果 git-filter-branch 本身不是 shell，那么方便函数（map()、skip_commit() 等）和 `-setup`参数就不能再在程序开始时执行一次，而是需要在每个用户过滤器中预置（因此每次提交都要重新执行）。"
 #. type: Plain text
 #: en/git-filter-branch.txt:541
 #, priority:90
 msgid "The https://github.com/newren/git-filter-repo/[git filter-repo] tool is an alternative to git-filter-branch which does not suffer from these performance problems or the safety problems (mentioned below). For those with existing tooling which relies upon git-filter-branch, 'git filter-repo' also provides https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely], a drop-in git-filter-branch replacement (with a few caveats).  While filter-lamely suffers from all the same safety issues as git-filter-branch, it at least ameliorates the performance issues a little."
-msgstr ""
+msgstr "https://github.com/newren/git-filter-repo/[git filter-repo] 工具是 git-filter-branch 的替代工具，它不存在这些性能问题或安全问题（如下所述）。对于那些现有工具依赖于 git-filter-branch 的用户，'git filter-repo' 还提供了 https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/filter-lamely[filter-lamely]，这是一个可直接替代 git-filter-branch 的工具（有一些注意事项）。 虽然 filter-lamely 与 git-filter-branch 存在同样的安全问题，但它至少在性能上稍有改善。"
 #. type: Title -
 #: en/git-filter-branch.txt:544
@@ -26642,145 +26630,145 @@ msgstr "安全性"
 #: en/git-filter-branch.txt:549
 #, priority:90
 msgid "git-filter-branch is riddled with gotchas resulting in various ways to easily corrupt repos or end up with a mess worse than what you started with:"
-msgstr ""
+msgstr "git-filter-branch 漏洞百出，有各种方法可以轻易破坏仓库，或者最后弄得一团糟，比一开始更糟："
 #. type: Plain text
 #: en/git-filter-branch.txt:563
 #, priority:90
 msgid "Someone can have a set of \"working and tested filters\" which they document or provide to a coworker, who then runs them on a different OS where the same commands are not working/tested (some examples in the git-filter-branch manpage are also affected by this).  BSD vs. GNU userland differences can really bite.  If lucky, error messages are spewed.  But just as likely, the commands either don't do the filtering requested, or silently corrupt by making some unwanted change.  The unwanted change may only affect a few commits, so it's not necessarily obvious either.  (The fact that problems won't necessarily be obvious means they are likely to go unnoticed until the rewritten history is in use for quite a while, at which point it's really hard to justify another flag-day for another rewrite.)"
-msgstr ""
+msgstr "有些人可能有一套 “经过测试的有效过滤器”，他们将其记录下来或提供给同事，但同事在不同的操作系统上运行这些过滤器时，相同的命令却无法正常工作或经过测试（git-filter-branch manpage 中的一些示例也受此影响）。 BSD 与 GNU 的用户态差异确实会让人头疼。 如果幸运的话，会出现错误信息。 但同样有可能的是，这些命令要么没有完成所要求的过滤，要么因为做了一些不必要的改动而无声无息地损坏了程序。 这些不必要的改动可能只影响到几个提交，所以也不一定很明显。 (问题不一定很明显这一事实意味着，在重写的历史被使用一段时间后，这些问题才有可能被发现。）"
 #. type: Plain text
 #: en/git-filter-branch.txt:573
 #, priority:90
 msgid "Filenames with spaces are often mishandled by shell snippets since they cause problems for shell pipelines.  Not everyone is familiar with find -print0, xargs -0, git-ls-files -z, etc.  Even people who are familiar with these may assume such flags are not relevant because someone else renamed any such files in their repo back before the person doing the filtering joined the project.  And often, even those familiar with handling arguments with spaces may not do so just because they aren't in the mindset of thinking about everything that could possibly go wrong."
-msgstr ""
+msgstr "带有空格的文件名通常会被 shell 片段错误处理，因为它们会给 shell 管道带来问题。 并非每个人都熟悉 find -print0、xargs -0、git-ls-files -z 等。 即使是熟悉这些的人，也可能会认为这些标记无关紧要，因为早在进行过滤的人加入项目之前，就有人重命名了他们的 repo 中的任何此类文件。 即使是熟悉处理带空格参数的人，也可能不会这么做，因为他们没有考虑到所有可能出错的地方。"
 #. type: Plain text
 #: en/git-filter-branch.txt:584
 #, priority:90
 msgid "Non-ascii filenames can be silently removed despite being in a desired directory.  Keeping only wanted paths is often done using pipelines like `git ls-files | grep -v ^WANTED_DIR/ | xargs git rm`.  ls-files will only quote filenames if needed, so folks may not notice that one of the files didn't match the regex (at least not until it's much too late).  Yes, someone who knows about core.quotePath can avoid this (unless they have other special characters like \\t, \\n, or \"), and people who use ls-files -z with something other than grep can avoid this, but that doesn't mean they will."
-msgstr ""
+msgstr "非英文字符串的文件名即使在想要的目录中，也会被悄悄移除。 ls-files 只在需要时才会引用文件名，因此人们可能不会注意到其中一个文件与通配符不匹配（至少在为时已晚之前不会注意到）。 是的，知道 core.quotePath 的人可以避免这种情况（除非他们有其他特殊字符，如 \\t、\\n 或 \" ），使用 ls-files -z 而不是 grep 的人也可以避免这种情况，但这并不意味着他们会这样做。"
 #. type: Plain text
 #: en/git-filter-branch.txt:591
 #, priority:90
 msgid "Similarly, when moving files around, one can find that filenames with non-ascii or special characters end up in a different directory, one that includes a double quote character.  (This is technically the same issue as above with quoting, but perhaps an interesting different way that it can and has manifested as a problem.)"
-msgstr ""
+msgstr "同样，在移动文件时，我们会发现带有非字符串或特殊字符的文件名最终会出现在不同的目录中，其中包括一个双引号字符。 (从技术上讲，这与上面的引号问题是一样的，但也许是一个有趣的不同方式，它可以并已经表现为一个问题）"
 #. type: Plain text
 #: en/git-filter-branch.txt:600
 #, priority:90
 msgid "It's far too easy to accidentally mix up old and new history.  It's still possible with any tool, but git-filter-branch almost invites it.  If lucky, the only downside is users getting frustrated that they don't know how to shrink their repo and remove the old stuff.  If unlucky, they merge old and new history and end up with multiple \"copies\" of each commit, some of which have unwanted or sensitive files and others which don't.  This comes about in multiple different ways:"
-msgstr ""
+msgstr "不小心混淆新旧历史太容易了。 任何工具都有可能发生这种情况，但 git-filter-branch 几乎是在自找麻烦。 如果幸运的话，唯一的坏处就是用户会因为不知道如何缩小他们的仓库并移除旧的东西而感到沮丧。 如果运气不好，他们就会合并新旧历史，最终每个提交都会有多个 “副本”，其中一些有不需要的文件或敏感文件，另一些则没有。 这种情况有多种不同的方式："
 #. type: Plain text
 #: en/git-filter-branch.txt:603
 #, priority:90
 msgid "the default to only doing a partial history rewrite ('--all' is not the default and few examples show it)"
-msgstr ""
+msgstr "默认情况下只进行部分历史重写（'--all' 不是默认值，而且很少有例子显示它）"
 #. type: Plain text
 #: en/git-filter-branch.txt:605
 #, priority:90
 msgid "the fact that there's no automatic post-run cleanup"
-msgstr ""
+msgstr "没有运行后的自动清理功能"
 #. type: Plain text
 #: en/git-filter-branch.txt:608
 #, priority:90
 msgid "the fact that --tag-name-filter (when used to rename tags) doesn't remove the old tags but just adds new ones with the new name"
-msgstr ""
+msgstr "标签名称过滤器（用于重命名标签时）不会删除旧标签，而只是用新名称添加新标签的事实"
 #. type: Plain text
 #: en/git-filter-branch.txt:617
 #, priority:90
 msgid "the fact that little educational information is provided to inform users of the ramifications of a rewrite and how to avoid mixing old and new history.  For example, this man page discusses how users need to understand that they need to rebase their changes for all their branches on top of new history (or delete and reclone), but that's only one of multiple concerns to consider.  See the \"DISCUSSION\" section of the git filter-repo manual page for more details."
-msgstr ""
+msgstr "事实上，几乎没有提供任何教育信息，让用户了解重写的后果，以及如何避免新旧历史混合。 例如，该手册页面讨论了用户需要了解如何将所有分支的改动重置到新历史之上（或删除并重新克隆），但这只是需要考虑的多个问题之一。 更多详情，请参阅 git filter-repo 手册页面的 “讨论” 部分。"
 #. type: Plain text
 #: en/git-filter-branch.txt:620
 #, priority:90
 msgid "Annotated tags can be accidentally converted to lightweight tags, due to either of two issues:"
-msgstr ""
+msgstr "注释标签可能会意外转换为轻量级标签，原因有两个："
 #. type: Plain text
 #: en/git-filter-branch.txt:625
 #, priority:90
 msgid "Someone can do a history rewrite, realize they messed up, restore from the backups in refs/original/, and then redo their git-filter-branch command.  (The backup in refs/original/ is not a real backup; it dereferences tags first.)"
-msgstr ""
+msgstr "有人可能会重写历史，意识到自己搞砸了，从 refs/original/ 中的备份恢复，然后重做 git-filter-branch 命令。 (refs/original/ 中的备份并不是真正的备份；它首先会取消引用标签）"
 #. type: Plain text
 #: en/git-filter-branch.txt:630
 #, priority:90
 msgid "Running git-filter-branch with either --tags or --all in your <rev-list options>.  In order to retain annotated tags as annotated, you must use --tag-name-filter (and must not have restored from refs/original/ in a previously botched rewrite)."
-msgstr ""
+msgstr "在运行 git-filter-branch 时，在 <rev-list 选项> 中使用 --tags 或 --all 选项。 为了将注释标签保留为注释标签，必须使用 --tag-name-filter（而且必须不是在之前失败的重写中从 refs/original/ 恢复的）。"
 #. type: Plain text
 #: en/git-filter-branch.txt:636
 #, priority:90
 msgid "Any commit messages that specify an encoding will become corrupted by the rewrite; git-filter-branch ignores the encoding, takes the original bytes, and feeds it to commit-tree without telling it the proper encoding.  (This happens whether or not --msg-filter is used.)"
-msgstr ""
+msgstr "任何指定编码的提交信息都会因为重写而损坏；git-filter-branch 会忽略编码，获取原始字节，并将其输入 commit-tree，而不会告诉它正确的编码。 (无论是否使用了 --msg-filter，都会发生这种情况）"
 #. type: Plain text
 #: en/git-filter-branch.txt:641
 #, priority:90
 msgid "Commit messages (even if they are all UTF-8) by default become corrupted due to not being updated -- any references to other commit hashes in commit messages will now refer to no-longer-extant commits."
-msgstr ""
+msgstr "默认情况下，提交信息（即使它们都是 UTF-8）会因未更新而损坏 --any 提交信息中对其他提交哈希值的引用现在会指向不再存在的提交。"
 #. type: Plain text
 #: en/git-filter-branch.txt:652
 #, priority:90
 msgid "There are no facilities for helping users find what unwanted crud they should delete, which means they are much more likely to have incomplete or partial cleanups that sometimes result in confusion and people wasting time trying to understand.  (For example, folks tend to just look for big files to delete instead of big directories or extensions, and once they do so, then sometime later folks using the new repository who are going through history will notice a build artifact directory that has some files but not others, or a cache of dependencies (node_modules or similar) which couldn't have ever been functional since it's missing some files.)"
-msgstr ""
+msgstr "没有任何工具可以帮助用户找到他们应该删除的不需要的垃圾，这意味着他们更有可能进行不完整或部分的清理，有时会造成混乱，让人浪费时间去理解。 (例如，人们倾向于只寻找要删除的大文件，而不是大目录或扩展名，一旦他们这样做了，那么使用新仓库的人在查看历史记录时就会发现构建工件目录中有一些文件但没有其他文件，或者依赖关系缓存（node_modules 或类似缓存）因为缺少了一些文件而无法正常运行）"
 #. type: Plain text
 #: en/git-filter-branch.txt:655
 #, priority:90
 msgid "If --prune-empty isn't specified, then the filtering process can create hoards of confusing empty commits"
-msgstr ""
+msgstr "如果不指定--prune-empty，过滤过程就会产生大量混乱的空提交"
 #. type: Plain text
 #: en/git-filter-branch.txt:659
 #, priority:90
 msgid "If --prune-empty is specified, then intentionally placed empty commits from before the filtering operation are also pruned instead of just pruning commits that became empty due to filtering rules."
-msgstr ""
+msgstr "如果指定了--prune-empty，那么过滤操作前有意放置的空提交也会被剪枝，而不只是剪枝因过滤规则而变为空的提交。"
 #. type: Plain text
 #: en/git-filter-branch.txt:662
 #, ignore-ellipsis, priority:90
 msgid "If --prune-empty is specified, sometimes empty commits are missed and left around anyway (a somewhat rare bug, but it happens...)"
-msgstr ""
+msgstr "如果指定--prune-empty，有时会漏掉一些空提交，但还是会保留下来（这是一个有点罕见的错误，但还是会发生......）"
 #. type: Plain text
 #: en/git-filter-branch.txt:666
 #, priority:90
 msgid "A minor issue, but users who have a goal to update all names and emails in a repository may be led to --env-filter which will only update authors and committers, missing taggers."
-msgstr ""
+msgstr "这只是个小问题，但如果用户的目标是更新版本库中的所有姓名和电子邮件，则可能会使用 --env-filter，它只会更新作者和提交者，而不会更新标记者。"
 #. type: Plain text
 #: en/git-filter-branch.txt:672
 #, priority:90
 msgid "If the user provides a --tag-name-filter that maps multiple tags to the same name, no warning or error is provided; git-filter-branch simply overwrites each tag in some undocumented pre-defined order resulting in only one tag at the end.  (A git-filter-branch regression test requires this surprising behavior.)"
-msgstr ""
+msgstr "如果用户提供了一个 --tag-name-filter 过滤器，将多个标签映射到同一个名字上，git-filter-branch 不会给出任何警告或错误信息，而只会按照某种未被记录的预定义顺序覆盖每个标签，导致最后只有一个标签。 (git-filter-branch 的回归测试需要这种令人惊讶的行为）"
 #. type: Plain text
 #: en/git-filter-branch.txt:675
 #, priority:90
 msgid "Also, the poor performance of git-filter-branch often leads to safety issues:"
-msgstr ""
+msgstr "此外，git-filter-branch 的性能不佳往往会导致安全问题："
 #. type: Plain text
 #: en/git-filter-branch.txt:692
 #, priority:90
 msgid "Coming up with the correct shell snippet to do the filtering you want is sometimes difficult unless you're just doing a trivial modification such as deleting a couple files.  Unfortunately, people often learn if the snippet is right or wrong by trying it out, but the rightness or wrongness can vary depending on special circumstances (spaces in filenames, non-ascii filenames, funny author names or emails, invalid timezones, presence of grafts or replace objects, etc.), meaning they may have to wait a long time, hit an error, then restart.  The performance of git-filter-branch is so bad that this cycle is painful, reducing the time available to carefully re-check (to say nothing about what it does to the patience of the person doing the rewrite even if they do technically have more time available).  This problem is extra compounded because errors from broken filters may not be shown for a long time and/or get lost in a sea of output.  Even worse, broken filters often just result in silent incorrect rewrites."
-msgstr ""
+msgstr "除非你只是做一些微不足道的修改，比如删除几个文件，否则有时很难找到正确的 shell 代码段来完成你想要的过滤。 不幸的是，人们往往通过尝试来判断代码段的正确与否，但正确与否会因特殊情况（文件名中的空格、非字符串文件名、有趣的作者姓名或电子邮件、无效的时区、存在嫁接或替换对象等）而有所不同，这意味着他们可能需要等待很长时间，遇到错误，然后重新启动。 git-filter-branch 的性能如此糟糕，以至于这种循环非常痛苦，减少了仔细重新检查的时间（更不用说对改写者耐心的影响了，即使他们在技术上有更多的时间）。 由于过滤器损坏导致的错误可能在很长时间内都不会显示出来，并且/或者在大量输出中丢失，因此这个问题变得更加复杂。 更糟糕的是，破损的过滤器往往只会导致无声的错误重写。"
 #. type: Plain text
 #: en/git-filter-branch.txt:700
 #, priority:90
 msgid "To top it all off, even when users finally find working commands, they naturally want to share them.  But they may be unaware that their repo didn't have some special cases that someone else's does.  So, when someone else with a different repository runs the same commands, they get hit by the problems above.  Or, the user just runs commands that really were vetted for special cases, but they run it on a different OS where it doesn't work, as noted above."
-msgstr ""
+msgstr "更糟糕的是，即使用户最终找到了可用的命令，他们自然也想分享这些命令。 但他们可能没有意识到，自己的软件源并不具备某些特殊情况，而别人的软件源却具备。 因此，当其他人使用不同的版本库运行相同的命令时，他们就会遇到上述问题。 或者，用户运行的命令确实经过了特殊情况审核，但他们在不同的操作系统上运行时却无法正常工作，如上所述。"
 #. type: Title =
 #: en/git-fmt-merge-msg.txt:2
@@ -28192,7 +28180,7 @@ msgstr "--pid-file=<file>"
 #: en/git-format-patch.txt:221
 #, priority:100
 msgid "Use the contents of <file> instead of the branch's description for generating the cover letter."
-msgstr ""
+msgstr "使用 <文件> 的内容而不是分支说明来生成求职信。"
 #. type: Labeled list
 #: en/git-format-patch.txt:222
@@ -28211,7 +28199,7 @@ msgstr "在主题行中不要使用标准的 '[PATCH]' 前缀，而要使用 '[<
 #: en/git-format-patch.txt:233
 #, priority:100
 msgid "The configuration variable `format.subjectPrefix` may also be used to configure a subject prefix to apply to a given repository for all patches. This is often useful on mailing lists which receive patches for several repositories and can be used to disambiguate the patches (with a value of e.g. \"PATCH my-project\")."
-msgstr ""
+msgstr "配置变量 `format.subjectPrefix` 也可用于配置主题前缀，以适用于指定仓库的所有补丁。这在接收多个仓库补丁的邮件列表中通常很有用，可用于消除补丁的歧义（例如值为 \"PATCH my-project\"）。"
 #. type: Labeled list
 #: en/git-format-patch.txt:234
@@ -29572,7 +29560,7 @@ msgstr "--max-pack-size=<n>"
 #: en/git-gc.txt:68
 #, priority:100
 msgid "When packing unreachable objects into a cruft pack, limit the size of new cruft packs to be at most `<n>` bytes. Overrides any value specified via the `gc.maxCruftSize` configuration. See the `--max-cruft-size` option of linkgit:git-repack[1] for more."
-msgstr ""
+msgstr "在将无法访问的对象打包到 Cruft 包时，限制新 Cruft 包的大小最多为 `<n>` 字节。覆盖通过 `gc.maxCruftSize` 配置指定的任何值。参见 linkgit:git-repack[1] 的 `-max-cruft-size`选项了解更多。"
 #. type: Labeled list
 #: en/git-gc.txt:69
@@ -33043,7 +33031,7 @@ msgstr "这个命令从 <文件> 参数或标准输入（如果没有指定 <文
 #: en/git-interpret-trailers.txt:43
 #, ignore-ellipsis, priority:100
 msgid "Otherwise, this command applies `trailer.*` configuration variables (which could potentially add new trailers, as well as reposition them), as well as any command line arguments that can override configuration variables (such as `--trailer=...` which could also add new trailers), to each input file. The result is emitted on the standard output."
-msgstr ""
+msgstr "否则，该命令会在每个输入文件中应用 `trailer.*` 配置变量（可能会添加新的拖车，也可能会调整拖车的位置），以及任何可以覆盖配置变量的命令行参数（例如 `--trailer=...`，也可能会添加新的拖车）。结果将输出到标准输出中。"
 #. type: Plain text
 #: en/git-interpret-trailers.txt:50
@@ -33083,7 +33071,7 @@ msgstr "这意味着修剪后的 <token> 和 <值> 将被 `': '`（一个冒号
 #: en/git-interpret-trailers.txt:75
 #, priority:100
 msgid "For convenience, a <keyAlias> can be configured to make using `--trailer` shorter to type on the command line. This can be configured using the 'trailer.<keyAlias>.key' configuration variable. The <keyAlias> must be a prefix of the full <key> string, although case sensitivity does not matter. For example, if you have"
-msgstr ""
+msgstr "为方便起见，可以配置 <keyAlias> 以缩短使用 `--trailer` 命令行的键入时间。可以使用 'trailer.<keyAlias>.key' 配置变量进行配置。<keyAlias> 必须是完整 <key> 字符串的前缀，但大小写敏感性并不重要。例如"
 #. type: delimited block -
 #: en/git-interpret-trailers.txt:78
@@ -33098,7 +33086,7 @@ msgstr ""
 #: en/git-interpret-trailers.txt:82
 #, priority:100
 msgid "in your configuration, you only need to specify `--trailer=\"sign: foo\"` on the command line instead of `--trailer=\"Signed-off-by: foo\"`."
-msgstr ""
+msgstr "时，只需在命令行中指定 `--trailer=\"sign: foo\"`，而不是 `-trailer=\"Signed-off-by:foo\"`。"
 #. type: Plain text
 #: en/git-interpret-trailers.txt:87
@@ -33272,7 +33260,7 @@ msgstr "--unfold"
 #: en/git-interpret-trailers.txt:173
 #, priority:100
 msgid "If a trailer has a value that runs over multiple lines (aka \"folded\"), reformat the value into a single line."
-msgstr ""
+msgstr "如果尾注中的某个值跨越多行（又称 “折叠”），则应将该值重新格式化为单行。"
 #. type: Labeled list
 #: en/git-interpret-trailers.txt:174
@@ -33284,7 +33272,7 @@ msgstr "--parse"
 #: en/git-interpret-trailers.txt:180
 #, priority:100
 msgid "A convenience alias for `--only-trailers --only-input --unfold`. This makes it easier to only see the trailers coming from the input without influencing them with any command line options or configuration variables, while also making the output machine-friendly with --unfold."
-msgstr ""
+msgstr "`--only-trailers--only-input--unfold` 的便利别名。这样就可以更方便地只查看来自输入的预告片，而不会受到任何命令行选项或配置变量的影响，同时还可以通过 --unfold 使输出对机器友好。"
 #. type: Labeled list
 #: en/git-interpret-trailers.txt:181
@@ -33463,7 +33451,7 @@ msgstr "trailer.<token>.key"
 #: en/git-interpret-trailers.txt:268
 #, ignore-ellipsis, priority:100
 msgid "Defines a <keyAlias> for the <key>. The <keyAlias> must be a prefix (case does not matter) of the <key>. For example, in `git config trailer.ack.key \"Acked-by\"` the \"Acked-by\" is the <key> and the \"ack\" is the <keyAlias>. This configuration allows the shorter `--trailer \"ack:...\"` invocation on the command line using the \"ack\" <keyAlias> instead of the longer `--trailer \"Acked-by:...\"`."
-msgstr ""
+msgstr "为 <key> 定义 <keyAlias> 。<keyAlias> 必须是 <key> 的前缀（大小写并不重要）。例如，在 `git config trailer.ack.key \"Acked-by\"` 中，\"Acked-by\" 是 <key>，\"ack\" 是 <keyAlias>。这种配置允许在命令行上使用 \"ack\" <keyAlias> 调用较短的 `-trailer \"ack:...\"`，而不是较长的 `-trailer \"Acked-by:...\"`。"
 #. type: Plain text
 #: en/git-interpret-trailers.txt:273
@@ -36142,19 +36130,19 @@ msgid ""
 "'git merge-file' [-L <current-name> [-L <base-name> [-L <other-name>]]]\n"
 "\t[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]\n"
 "\t[--[no-]diff3] <current-file> <base-file> <other-file>\n"
-msgstr ""
+msgstr "'git merge-file' [-L <当前名称> [-L <基本名称> [-L <另一个名称>]]]\n\t[--ours|--theirs|--union] [-p|--stdout] [-q|--quiet] [--marker-size=<n>]\n\t[--[no-]diff3] <当前文件> <基础文件> <另一个文件>\n"
 #. type: Plain text
 #: en/git-merge-file.txt:25
 #, priority:90
 msgid "'git merge-file' incorporates all changes that lead from the `<base-file>` to `<other-file>` into `<current-file>`. The result ordinarily goes into `<current-file>`. 'git merge-file' is useful for combining separate changes to an original. Suppose `<base-file>` is the original, and both `<current-file>` and `<other-file>` are modifications of `<base-file>`, then 'git merge-file' combines both changes."
-msgstr ""
+msgstr "'git merge-file' 会将从 `<基础文件>` 到 `<另一个文件>` 的所有改动合并到 `<当前文件>` 中。合并后的结果通常会放入 `<当前文件>`。'git merge-file' 可用于合并对原文件的不同改动。假设 `<基础文件>`是原文件，而 `<当前文件>` 和 `<另一个文件>` 都是对 `<基础文件>` 的修改，那么 'git merge-file' 会合并这两处修改。"
 #. type: Plain text
 #: en/git-merge-file.txt:30
 #, priority:90
 msgid "A conflict occurs if both `<current-file>` and `<other-file>` have changes in a common segment of lines. If a conflict is found, 'git merge-file' normally outputs a warning and brackets the conflict with lines containing <<<<<<< and >>>>>>> markers. A typical conflict will look like this:"
-msgstr ""
+msgstr "如果 `<当前文件>` 和 `<另一个文件>` 在共同的行段中都有改动，就会发生冲突。如果发现冲突，\"git merge-file\" 通常会输出警告，并用包含 <<<<<<< 和 >>>>>>> 标记的行括弧括住冲突。典型的冲突如下"
 #. type: Plain text
 #: en/git-merge-file.txt:36
@@ -36165,7 +36153,7 @@ msgid ""
 "\t=======\n"
 "\tlines in file B\n"
 "\t>>>>>>> B\n"
-msgstr ""
+msgstr "\t<<<<<<< A\n\t文件 A 中的某几行\n\t=======\n\t文件 B 中的某几行\n\t>>>>>>> B\n"
 #. type: Plain text
 #: en/git-merge-file.txt:42
@@ -47418,7 +47406,7 @@ msgstr "立即过期超过 `<approxidate>` 的不可访问对象，而不是等
 #: en/git-repack.txt:87
 #, priority:100
 msgid "Repack cruft objects into packs as large as `<n>` bytes before creating new packs. As long as there are enough cruft packs smaller than `<n>`, repacking will cause a new cruft pack to be created containing objects from any combined cruft packs, along with any new unreachable objects. Cruft packs larger than `<n>` will not be modified. When the new cruft pack is larger than `<n>` bytes, it will be split into multiple packs, all of which are guaranteed to be at most `<n>` bytes in size. Only useful with `--cruft -d`."
-msgstr ""
+msgstr "在创建新的数据包之前，会先将 Cruft 物件重新打包到大小为 `<n>` 字节的数据包中。只要有足够的小于 `<n>` 的 Cruft 包，重新打包将导致创建一个新的 Cruft 包，其中包含来自任何合并 Cruft 包的对象，以及任何新的无法访问的对象。大于 `<n>` 的压缩包不会被修改。当新的 Cruft 包大于 `<n>` 字节时，它将被拆分成多个包，所有包的大小保证最多为 `<n>` 字节。仅在使用 `--cruft -d` 时有用。"
 #. type: Labeled list
 #: en/git-repack.txt:88
@@ -47490,7 +47478,7 @@ msgstr "每个输出包文件的最大大小。大小可以后缀为 \"k\"、\"m
 #: en/git-repack.txt:168
 #, priority:100
 msgid "Remove objects matching the filter specification from the resulting packfile and put them into a separate packfile. Note that objects used in the working directory are not filtered out. So for the split to fully work, it's best to perform it in a bare repo and to use the `-a` and `-d` options along with this option.  Also `--no-write-bitmap-index` (or the `repack.writebitmaps` config option set to `false`) should be used otherwise writing bitmap index will fail, as it supposes a single packfile containing all the objects. See linkgit:git-rev-list[1] for valid `<filter-spec>` forms."
-msgstr ""
+msgstr "从生成的包文件中移除符合过滤规范的对象，并将其放入一个单独的包文件中。请注意，工作目录中使用的对象不会被过滤掉。因此，要使拆分完全有效，最好在裸 仓库中执行拆分，并将 `-a` 和 `-d` 选项与此选项一起使用。 此外，还应使用 `--no-write-bitmap-index`（或将 `repack.writebitmaps` 配置选项设为 `false`），否则写入位图索引会失败，因为它假定只有一个包文件包含所有对象。有关有效的 `<filter-spec>` 形式，请参见 linkgit:git-rev-list[1]。"
 #. type: Labeled list
 #: en/git-repack.txt:169
@@ -47502,7 +47490,7 @@ msgstr "--directory=<dir>"
 #: en/git-repack.txt:179
 #, priority:100
 msgid "Write the pack containing filtered out objects to the directory `<dir>`. Only useful with `--filter`. This can be used for putting the pack on a separate object directory that is accessed through the Git alternates mechanism. **WARNING:** If the packfile containing the filtered out objects is not accessible, the repo can become corrupt as it might not be possible to access the objects in that packfile. See the `objects` and `objects/info/alternates` sections of linkgit:gitrepository-layout[5]."
-msgstr ""
+msgstr "将包含筛选出的对象的数据包写入目录 `<目录>`。仅在使用 `--filter` 时有用。这可用于将数据包放在通过 Git 替代机制访问的单独对象目录中。**警告：** 如果包含过滤掉的对象的包文件无法访问，则 repo 可能会损坏，因为可能无法访问该包文件的对象。请参阅 linkgit:gitrepository-layout[5] 的 `objects` 和 `objects/info/alternates` 部分。"
 #. type: Labeled list
 #: en/git-repack.txt:181
@@ -49628,7 +49616,7 @@ msgstr "将 master 中倒数第五次提交（包含）到 master 中倒数第
 #: en/git-revert.txt:154
 #, priority:100
 msgid "While git creates a basic commit message automatically, it is _strongly_ recommended to explain why the original commit is being reverted.  In addition, repeatedly reverting reverts will result in increasingly unwieldy subject lines, for example 'Reapply \"Reapply \"<original subject>\"\"'.  Please consider rewording these to be shorter and more unique."
-msgstr ""
+msgstr "虽然 git 会自动创建基本的提交信息，但强烈建议解释为什么要还原原始提交。 此外，反复还原会导致主题行越来越笨重，例如 \"Reapply \"Reapply \"<original subject>\"\"。 请考虑重新措辞，使其更简短、更独特。"
 #. type: Title =
 #: en/git-rev-list.txt:2
@@ -54702,19 +54690,19 @@ msgstr ""
 #: en/git-status.txt:248
 #, priority:280
 msgid "Submodules have more state and instead report"
-msgstr ""
+msgstr "子模块有更多的状态，而不是报告"
 #. type: Plain text
 #: en/git-status.txt:250
 #, priority:280
 msgid "'M' = the submodule has a different HEAD than recorded in the index"
-msgstr ""
+msgstr "'M' = 子模块的 HEAD 与索引中记录的不同"
 #. type: Plain text
 #: en/git-status.txt:251
 #, priority:280
 msgid "'m' = the submodule has modified content"
-msgstr ""
+msgstr "'m' = 子模块修改了内容"
 #. type: Plain text
 #: en/git-status.txt:252
@@ -54727,7 +54715,7 @@ msgstr "'no' - 不显示未被追踪的文件\n"
 #: en/git-status.txt:255
 #, priority:280
 msgid "This is since modified content or untracked files in a submodule cannot be added via `git add` in the superproject to prepare a commit."
-msgstr ""
+msgstr "这是因为子模块中已修改的内容或未跟踪的文件无法在超级项目中通过 `git add` 添加，以准备提交。"
 #. type: Plain text
 #: en/git-status.txt:258
@@ -66566,7 +66554,7 @@ msgstr "'%x00'"
 #: en/pretty-formats.txt:128
 #, priority:260
 msgid "'%x' followed by two hexadecimal digits is replaced with a byte with the hexadecimal digits' value (we will call this \"literal formatting code\" in the rest of this document)."
-msgstr ""
+msgstr "'%x' 后跟两个十六进制数字，会被一个包含十六进制数字值的字节替换（在本文档的其余部分，我们称之为 “字面格式化代码”）。"
 #. type: Plain text
 #: en/pretty-formats.txt:130
@@ -67176,55 +67164,55 @@ msgstr "'%(description[:options])'"
 #: en/pretty-formats.txt:232
 #, priority:260
 msgid "ref names with custom decorations. The `decorate` string may be followed by a colon and zero or more comma-separated options. Option values may contain literal formatting codes. These must be used for commas (`%x2C`) and closing parentheses (`%x29`), due to their role in the option syntax."
-msgstr ""
+msgstr "自定义装饰的引用名称。`decorate` 字符串后面可以是冒号和零个或多个以逗号分隔的选项。选项值可能包含字面格式化代码。由于逗号（`%x2C`）和结尾括号（`%x29`）在选项语法中的作用，因此必须使用这些代码。"
 #. type: Plain text
 #: en/pretty-formats.txt:234
 #, priority:260
 msgid "'prefix=<value>': Shown before the list of ref names.  Defaults to \"{nbsp}`(`\"."
-msgstr ""
+msgstr "'prefix=<值>'： 显示在引用名称列表之前。 默认为 \"{nbsp}`(`\"。"
 #. type: Plain text
 #: en/pretty-formats.txt:235
 #, priority:260
 msgid "'suffix=<value>': Shown after the list of ref names.  Defaults to \"`)`\"."
-msgstr ""
+msgstr "'suffix=<值>'： 显示在引用名称列表之后。 默认为 \"`)`\"。"
 #. type: Plain text
 #: en/pretty-formats.txt:236
 #, priority:260
 msgid "'separator=<value>': Shown between ref names.  Defaults to \"`,`{nbsp}\"."
-msgstr ""
+msgstr "'separator=<值>'： 显示在引用名称之间。 默认为 \"`,`{nbsp}\"。"
 #. type: Plain text
 #: en/pretty-formats.txt:237
 #, priority:260
 msgid "'pointer=<value>': Shown between HEAD and the branch it points to, if any."
-msgstr ""
+msgstr "'point=<值>'： 显示在 HEAD 和其指向的分支（如果有）之间。"
 #. type: Plain text
 #: en/pretty-formats.txt:238
 #, priority:260
 msgid "Defaults to \"{nbsp}`->`{nbsp}\"."
-msgstr ""
+msgstr "默认为 \"{nbsp}`->`{nbsp}\"。"
 #. type: Plain text
 #: en/pretty-formats.txt:239
 #, priority:260
 msgid "'tag=<value>': Shown before tag names. Defaults to \"`tag:`{nbsp}\"."
-msgstr ""
+msgstr "'tag=<值>'： 显示在标记名称之前。默认为 \"`tag:`{nbsp}\"。"
 #. type: Plain text
 #: en/pretty-formats.txt:243
 #, priority:260
 msgid "For example, to produce decorations with no wrapping or tag annotations, and spaces as separators:"
-msgstr ""
+msgstr "例如，制作不带包装或标签注释的装饰，并用空格作为分隔符："
 #. type: Plain text
 #: en/pretty-formats.txt:245
 #, priority:260
 msgid "`%(decorate:prefix=,suffix=,tag=,separator= )`"
-msgstr ""
+msgstr "`%(decorate:prefix=,suffix=,tag=,separator= )`"
 #. type: Labeled list
 #: en/pretty-formats.txt:246
@@ -67795,7 +67783,7 @@ msgstr "--show-notes-by-default"
 #: en/pretty-options.txt:93
 #, priority:260
 msgid "Show the default notes unless options for displaying specific notes are given."
-msgstr ""
+msgstr "显示默认备注，除非给出了显示特定备注的选项。"
 #. type: Labeled list
 #: en/pretty-options.txt:94
@@ -69229,7 +69217,7 @@ msgstr "在寻找要排除的提交（用'{caret}'）时，在看到合并提交
 #: en/rev-list-options.txt:158
 #, priority:260
 msgid "Reverses the meaning of the '{caret}' prefix (or lack thereof)  for all following revision specifiers, up to the next `--not`.  When used on the command line before --stdin, the revisions passed through stdin will not be affected by it. Conversely, when passed via standard input, the revisions passed on the command line will not be affected by it."
-msgstr ""
+msgstr "反转 '{caret}' 前缀（或无前缀）对后面所有版本说明符的意义，直到下一个 `--not`。 在 --stdin 之前的命令行中使用时，通过标准输入流传递的修订版本不会受其影响。反之，通过标准输入传递时，命令行上传递的修订版本也不会受其影响。"
 #. type: Plain text
 #: en/rev-list-options.txt:162