Mercurial - 什么是 "future auditing"？
Mercurial - what is "future auditing"?
我正在阅读 the docs。在关于 Mercurial 的书签系统的部分，我读到：
Bookmarks can be used as an alternative to NamedBranches for tracking
multiple lines of development. Systems like Mercurial, CVS, and
Subversion store their branch information as a permanent part of each
commit. This is useful for future auditing of long-lived branches, as
it’s always possible to identify which branch a commit was introduced
on. Git, by contrast, has “branches” that are not stored in history,
which is useful for working with numerous short-lived feature
branches, but makes future auditing impossible.
我试着在网上搜索 "future auditing" 与 mercurial 有关的内容，但几乎每篇文章的内容都与上面引用的内容完全相同，就好像他们都是从同一个地方抓取该文档一样。
这个神秘的 "future auditing" 是什么，据说在 git 中是不可能的？
谢谢。
“未来审计”不是一个技术术语，它只是“供未来参考”、“供未来分析”的另一种说法。这就是为什么谷歌搜索 mercurial future auditing 不会给你那么多有用的结果。
附带说明，在 Git 中，您可以通过在 git merge 上使用 --no-ff 选项来实现可读的历史记录，这可以防止快进分支并强制创建合并提交。这样，您将始终在历史记录中有一个可见的分支，从而更容易了解特定提交是在哪个功能分支的上下文中设计的。出于这个原因，像 Git Flow 这样的流行工作流程强制使用 --no-ff。
上图来自Git Flow website。它显示了在可以快进但用户选择强制合并提交的情况下 --no-ff 对历史的影响。
这与“Deleting git branch looses audit”中提到的审计相同：
git 中的分支可以随时删除或重命名。
if the merge was not a fast-forward you will see that the commits were made to a branch that was later merged, but you won't know what the branch was originally called.
您可以在 More On Mercurial vs. Git (with Graphs!) (2011)
中看到它的插图
如果您想要一些标识符与您的开发人员推送的每个提交相关联，请让他们将该标识符与他们推送的每个提交相关联。在这里，这里有一个 commit-msg 过滤器，它将它从 repo 的配置中拉出来：
sed -si "/^###audit identifer:.*###/d
$ s/.*$/&\n###audit identifier: $(printf %s `git config x-workdata.bugid`)###" ""
将其放入您的 commit-msg 挂钩（pace 语法），每次提交都会记录 x-workdata.bugid 配置项。
但是，(a) 没有理由要求开发人员以特定方式记录该 id，并且 (b) 更没有理由要求该 id 是他们在处理此特定时使用的唯一分支名称努力。如果他们尝试三种不同的方式，那么他们必须返回并使用以完全正确的 ID 命名的分支重新设置最好的基线，因为有一些强制要求这是通过提交记录该 ID 的唯一方法？太可笑了。
我正在阅读 the docs。在关于 Mercurial 的书签系统的部分，我读到：
Bookmarks can be used as an alternative to NamedBranches for tracking multiple lines of development. Systems like Mercurial, CVS, and Subversion store their branch information as a permanent part of each commit. This is useful for future auditing of long-lived branches, as it’s always possible to identify which branch a commit was introduced on. Git, by contrast, has “branches” that are not stored in history, which is useful for working with numerous short-lived feature branches, but makes future auditing impossible.
我试着在网上搜索 "future auditing" 与 mercurial 有关的内容，但几乎每篇文章的内容都与上面引用的内容完全相同，就好像他们都是从同一个地方抓取该文档一样。
这个神秘的 "future auditing" 是什么，据说在 git 中是不可能的？
谢谢。
“未来审计”不是一个技术术语，它只是“供未来参考”、“供未来分析”的另一种说法。这就是为什么谷歌搜索 mercurial future auditing 不会给你那么多有用的结果。
附带说明，在 Git 中，您可以通过在 git merge 上使用 --no-ff 选项来实现可读的历史记录，这可以防止快进分支并强制创建合并提交。这样，您将始终在历史记录中有一个可见的分支，从而更容易了解特定提交是在哪个功能分支的上下文中设计的。出于这个原因，像 Git Flow 这样的流行工作流程强制使用 --no-ff。
上图来自Git Flow website。它显示了在可以快进但用户选择强制合并提交的情况下 --no-ff 对历史的影响。
这与“Deleting git branch looses audit”中提到的审计相同：
git 中的分支可以随时删除或重命名。
if the merge was not a fast-forward you will see that the commits were made to a branch that was later merged, but you won't know what the branch was originally called.
您可以在 More On Mercurial vs. Git (with Graphs!) (2011)
中看到它的插图如果您想要一些标识符与您的开发人员推送的每个提交相关联，请让他们将该标识符与他们推送的每个提交相关联。在这里，这里有一个 commit-msg 过滤器，它将它从 repo 的配置中拉出来：
sed -si "/^###audit identifer:.*###/d
$ s/.*$/&\n###audit identifier: $(printf %s `git config x-workdata.bugid`)###" ""
将其放入您的 commit-msg 挂钩（pace 语法），每次提交都会记录 x-workdata.bugid 配置项。
但是，(a) 没有理由要求开发人员以特定方式记录该 id，并且 (b) 更没有理由要求该 id 是他们在处理此特定时使用的唯一分支名称努力。如果他们尝试三种不同的方式，那么他们必须返回并使用以完全正确的 ID 命名的分支重新设置最好的基线，因为有一些强制要求这是通过提交记录该 ID 的唯一方法？太可笑了。