Git，如何忽略交换线路？

Question

我有一个配置文件，当我启动服务器时会更改，但是唯一的更改是交换线路。它不会影响文件的内容，也不会影响行的位置，因为服务器会在获取行的位置重写数据。我该如何预防？

我想到了一个静态文件夹，然后将我的配置文件放在这里，然后在提交更改之前，我只是复制了它们，但是我不知道我是否可以使用git自动完成。

我正在谈论的示例：

我运行服务器之前：

    frosted-ice:
      enabled: true
      delay:
        min: 20
        max: 40
    lootables:
      auto-replenish: false
      restrict-player-reloot: true
      reset-seed-on-fill: true
      max-refills: -1
      refresh-min: 12h
      refresh-max: 2d

运行服务器后：

    lootables:
      auto-replenish: false
      restrict-player-reloot: true
      refresh-min: 12h
      refresh-max: 2d
      reset-seed-on-fill: true
      max-refills: -1
    frosted-ice:
      enabled: true
      delay:
        min: 20
        max: 40

Answer 1

您可以考虑在提交过程中插入clean filter。您将需要编写干净的过滤器本身，然后在Git配置中添加过滤器驱动程序configuration（告诉Git如何调用干净的过滤器），并添加.gitattributes文件以将该特定文件标记为需要通过干净的过滤器。

背景

Git存储提交，并且提交保存content-一组文件的文件数据，每个提交一个文件集合-但在大多数情况下，Git不知道该内容是什么[[means 。并且：每个提交都存储一个每个文件的完整快照-因此，如果文件的含义相同，并且无论如何您都在进行新的提交，则仅使用重新排列的行。

我说

相对无害

，因为有两个明显的缺点：

• 当您是人类时，将先前的提交（新提交的父级）与随后的提交（新提交或子级）进行比较，您会看到config.yml或此文件的名称是

  更改

。这种变化只是杂音，但是您会参见，因为Git不会解释内容，它只是说：嘿，这个文件已更改。

Git拥有巧妙的技术，可以使存储库的整体规模较小，尽管事实是每个提交都存储了每个文件的完整副本。第一种技术非常简单：Git将每个内容

哈希

放入Git称为blob object的内容，该内容通过其哈希ID进行检索，就像Git检索通过其唯一哈希ID提交的方式一样。这种哈希对输入数据的每个字节（或位）的值和位置非常敏感。因此，与文件的先前副本完全匹配的文件将带有same哈希ID，但以任何方式更改的文件（包括仅重新排列其中某些块的文件）都不会。] >换句话说，这种重新安排文件内容的方法击败了Git压缩文件的重复副本的第一种也是最有效的方法。

您说：

[[它]不管行在哪里，因为服务器会在获得它们的位置重写数据。我该如何预防？

并在评论中添加：

[数据[编码为] yaml [并代表无序映射]

在YAML文件中的[[随机

周围换行会改变存储的数据，但是交换

无序映射中各个键值对（可能跨越或不跨越一条或多条线）的位置]

确实不会使整体映射保持不变（因为映射本身是无序的。）这里的问题是，Git不知道这是一个以YAML行表示的无序映射。 您可能知道，但是Git却不知道，并且没有简单的方法告诉Git，因为Git不知道JSON的YAML，也不知道a hole in a file的YAML。

最后，您只有三个选择：

忽略噪音和压缩不足。也就是说，忍受这个。不会
1. fail，这很烦人。

尽管文件中包含无序映射，但

教任何内容以适当的方式重写此文件以使用

稳定顺序] >>。也就是说，为了使数据

在YAML中表示为行

，任何表示映射的内容都必须对映射进行排序

，因为行具有顺序。编写此YAML文件的程序可以在编写之前对映射进行排序。参见What is stability in sorting algorithms and why is it important?插入您自己的排序。

方法1是最简单的方法，但缺点是会让您感到烦恼。 （磁盘空间很便宜，而且Git的辅助压缩技术最终还是会压缩掉大部分内容，因此saves-space参数可能很弱，但是恼人的参数却很强大。）

我个人认为第二种方法是最好的，但是如果您不控制其他程序，则可能无法修复它。

第三种方法意味着您必须编写自己的程序。如果您可以访问YAML读写器，并且可以轻松地构造，排序和写回YAML文件中的有序映射，请考虑这样做。

使用干净的过滤器

要使用干净的过滤器，您需要为其提供名称。您可以称您的

sort-yaml-dictionary或类似名称。这些行将进入.git/config或$HOME/.gitconfig或类似文件：

[filter "sort-yaml-dictionary"]
    clean = the-program-you-wrote

您也不必在这里定义

smudge过滤器

，但是如果您愿意，也可以使用将其输入复制回其输出的程序，例如cat。有关更多详细信息，请参见the gitattributes documentation。

然后，在.giattributes文件中，添加以下行：config.yml filter=sort-yaml-dictionary

这告诉Git：

每次我在git add上运行config.yml时，都不要只是将[工作树]文件复制到Git的索引中。而是

read文件。将其数据发送到clean驱动程序的sort-yaml-dictionary过滤器，作为该过滤器的输入。读回该过滤器的输出。将结果数据以文件的原始名称存储在索引中，在本例中为config.yml。
• 由于您的程序读取，然后进行排序（以稳定的字典键-值顺序排序），然后写回配置，结果将是进入[[commits的是config.yml文件的排序版本，无论工作树版本是什么。由您决定是否让程序也
就地对工作树副本进行排序（即，先读取然后重写工作树副本），但是如果这样做，请确保执行

完全在之前

或完全在之后已将文件复制到索引。否则，冒着写入工作树文件

while

的风险。Git试图读取工作树文件以将数据发送到过滤程序。Do not过滤工作树文件。过滤输入到您的程序。此输入实际上可能与工作树文件的内容不匹配。 （clean筛选器可以通过git merge在根本不在工作树中的内容上调用。）