.gitattributes 涂抹/清洁过滤器的汞等价物

Question

受this 答案的启发，我想知道是否有一种方法可以在Mercurial 中获得与.gitattributes 文件中为git 指定的涂抹/清洁过滤器所获得的行为相同的行为。也就是说，在提交之前对某些文件进行一些预处理，而不影响工作副本。

您可以在gitattributes 的filters 小节的git documentation 中找到我的意思的正确描述。另外，来自Pro Git book：

事实证明，您可以编写自己的过滤器，以便在提交/签出时在文件中进行替换。这些被称为“清洁”和“涂抹”过滤器。在 .gitattributes 文件中，您可以为特定路径设置过滤器，然后设置脚本在文件被签出之前（“smudge”，参见Figure 8-2）和在文件暂存之前（“clean ”，请参阅Figure 8-3)。这些过滤器可以设置为做各种有趣的事情。

我的用例类似于this other question 中所述的用例：在将某些文件提交到存储库之前清理部分文件但不影响工作副本。

我能找到的最相似的东西是 Mercurial 的 encode/decode 功能。问题是documentation on this feature 非常简洁（我在其他任何地方都找不到太多信息）。

但是，encode/decode 功能被标记为unloved feature。这是为什么？这是否意味着有更好的方法来做它的工作？出于某种原因，没有适当的方法可以做到这一点，但我应该像其他人一样选择这个方法吗？

Answer 1

查看您的用例，在存储库上覆盖本地修改的预期方法通常是使用 MQ 扩展，它允许您在本地应用补丁，这些补丁不会被推送到远程存储库，并且可以应用和不应用为需要（并且可以将它们自己置于版本控制之下）。

一般来说，在签入或签出时自动修改文件是有问题的：

1. 它可能无法与您的其他 VCS 相关工具很好地交互，尤其是那些将补丁公开为差异或重命名文件的部分。
2. 一般容易出错；您正在签入一个从未测试过的版本，并且必须确保编码/解码步骤正确往返。
3. 编码和解码设置实际上并不是存储库的一部分，而是您的 VCS 配置的一部分。例如，这可能会导致您意外输入密码，因为您忘记在新结帐时正确设置配置。特别是，新的hg clone 不会复制.hg/hgrc，因此可能会检出未解码的文件。

当您使用 VCS 处理永久和临时工件时，您遇到的更大问题是您试图让它做一些它不是为它设计的事情。您缺少的是从永久工件创建临时工件的构建或部署步骤，可能与本地配置（例如，通过模板系统）结合使用。这也可以与防止意外签入临时工件的挂钩结合使用。

也就是说，如果您绝对想使用过滤器，它的工作原理如下：您需要匹配 [encode] 和 [decode] 部分。每个部分都有一系列pattern = shell-command 条目，其中pattern 描述一个文件名或一组文件名，shell-command 是将输入文件转换为输出文件的shell 命令。该命令可以以pipe:（这是默认值）作为前缀，然后必须将标准输入转换为标准输出或tempfile:，在这种情况下，该命令会转换命令行中给出的文件（由占位符@指定） 987654330@ 和 OUTFILE)。

例子：

[encode]
secretfile = pipe: sed -e 's/FOO/BAR/g'
[decode]
secretfile = pipe: sed -e 's/BAR/FOO/g'

使用临时文件：

[encode]
secretfile = tempfile: sed -e 's/FOO/BAR/g' <INFILE >OUTFILE
[decode]
secretfile = tempfile: sed -e 's/BAR/FOO/g' <INFILE >OUTFILE

这两个示例在签入时将出现的FOO 转换为BAR，在结账时将BAR 转换为FOO。请注意这实际上是如何正确往返的：如果文件在签入时包含字符串BAR，则在签出时它将变为FOO。编写在所有情况下都能正确执行此操作的过滤器可能相当棘手。这就是为什么单独的构建步骤几乎总是比在签入和签出中添加额外的魔法更好的原因之一。