使用Git处理subversion：忽略对跟踪文件的修改

Question

我目前正在使用subversion存储库，但我正在使用git在我的机器上本地工作。它使工作变得更容易，但它也使得subversion repo中的一些不良行为非常明显，这给我带来了麻烦。

在下拉代码之后有一个有点复杂的本地构建过程，它创建（并且不幸地修改）了许多文件。显然，这些更改并不意味着要提交回存储库。不幸的是，构建过程实际上正在修改一些跟踪文件（是的，很可能是因为有人错误地将这些构建工件提交到了subversion存储库）。由于这些是修改，将它们添加到我的忽略文件中对我没有任何帮助。

我可以避免检查这些更改，我很简单，不会暂存或提交它们，但是如果没有暂停的本地更改意味着我不能在没有先清理它们的情况下进行更改。

我想知道的是，是否有任何方法可以忽略对一组跟踪文件的未来更改？或者，是否有另一种方法来处理我遇到的问题，或者我只需要告诉谁签入这些文件来清理它们？

Answer 1

作为Nathan said，清理这些文件（取消跟踪）是明智之举。

但是如果你必须忽略跟踪文件（当忽略文件时不是本机Git方式：Git只忽略非跟踪文件），你可以设置一个复制内容的进程您要忽略的文件，以及在提交时恢复。

我最初认为smudge/clean process，即gitattributes filter driver可以解决问题：

，其中：

• 涂抹过程将复制这些文件（更新工作树时）
• 在构建期间进行一些修改
• 干净步骤（在提交期间）将使用步骤1中的副本擦除文件内容。

但是，stated in this post，这意味着通过添加有状态上下文（即文件的完整路径名称）来滥用此无状态文件内容转换脏污/清洁）。
这是J.C. Hamano明确禁止的：

  

虽然我最初考虑使用路径名插入“%P”，但我最终决定反对它，以阻止人们滥用过滤器进行状态转换，根据时间，路径名，提交，分支和内容改变结果

关于所有机制的

甚至Linus Torvalds had some reservations：

  

我不得不说，我显然不是玩游戏的忠实粉丝，但差异非常干净。

     

他们真的有用吗？我不知道。我对这个功能的任何实际用户意味着什么感到有些紧张，但我不得不承认被一个干净的实现所吸引。

     

我怀疑这会引起一些人的抱怨，但我还怀疑人们实际上最终会把这种事情弄得一团糟然后责怪我们并造成巨大的痛苦当我们支持这个并且人们想要“不再干净的扩展语义”时。

     

但我不确定真正有效的论证是多么有效。我碰巧相信“给他们绳索”的理念。我认为你可以用这个来扼杀自己，但嘿，任何做这件事的人都应该责备自己

---

因此，添加某种保存/恢复机制（并有效忽略对Git中一组跟踪的文件的任何更改）的正确位置将在 hooks < /强>：

• post-checkout ：在更新工作树后运行git checkout时调用。在那里，您可以运行一个脚本来收集要忽略的所有文件并将其保存在某处。

• pre-commit ：在获取建议的提交日志消息并进行提交之前，您可以运行第二个脚本来恢复这些文件的内容。

Answer 2

除非发生严重的政治性脑损伤，否则从源代码控制中删除工件是正确的步骤。 （或者更确切地说，“最方便”的步骤，它始终是正确的步骤。）

我不知道告诉git忽略对跟踪文件的更改的方法。