hgignore 中奇怪的负前瞻处理答案

【问题标题】：Weird negative lookahead handling in hgignorehgignore 中奇怪的负前瞻处理
【发布时间】：2012-05-03 14:20:37
【问题描述】：

在一个巨大的源代码树中，我希望 Mercurial 只跟踪一个子文件夹。

specific/component/subfolder

在任何像样的正则表达式工具（Regex Coach、regexpal.com）中，以下内容绝对足够（并且可以理解）

^(?!specific/component/subfolder).+

同时 .hgignore 坚持要拥有

^(?!extras).+
^extras/(?!extensions).+
^extras/extensions/(?!sharing).+

只要我把斜线放在前瞻组中，什么都不会通过。

在称这是一个错误（可能是另一个本土的正则表达式解析器？）之前，我问一下集体智能:-)

关于 hgignore 想要做什么的间接线索的学分

【问题讨论】：

【解决方案1】：

只是不要在 .hgignore 中使用负前瞻。真的。每次有人在 Stack Overflow 中建议它时，我都会让他们知道它不能很好地工作，因为它不是预期的功能。如果 Mercurial 的 .hgignore 文件应该是一个白名单系统，它就会有一个真正的白名单语法。这是一个黑名单，应该这样使用。

否定的前瞻语法几乎可以正常工作，因为它不是一个本土的正则表达式解析器——它是 Python 内置的，并且不妨碍禁用否定前瞻似乎有点过头了，但也许是更好的选择。

两种解决方案比使用“永不满足”的负面前瞻性处理方式更好：

说真的。这不是一个预期的功能，它永远不会很好地工作，但由于向后兼容的原因不能被删除。

【讨论】：

那么从大量的建议来看，实际的白名单可能是一个有用的功能，对吧？ :) 就我而言，您的任何建议都不适用，这可能是一种流行的情况。 Hg 是 master 上游 svn 的开发补充。所以我们需要补丁兼容 - 根在同一目录中。并且开发人员在每次创建东西时都无法记住手动添加。更糟糕的是，当它由一些 RAD 工具为他们创建时。我很庆幸至少这种骇人听闻的白名单是有效的。
我并没有决定只制作忽略黑名单，但我确实认为这是正确的。很容易做到hg status --unknown --no-status > .hgignore 忽略当前存在和未添加的所有内容。确保人们至少一次看到他们选择不保护的所有内容，并在其前面使用“?”，这似乎符合我从 Mercurial 的 ui 中观察到的 err-on-the-side-of-caution。
链接最终出现在 Bugzilla 主页上。这可能是最新的：bz.selenic.com/show_bug.cgi?id=712 如果这方面有任何进展，它看起来像是最终的信息来源。谢谢。
是的，这是 Matt 用他自己的话说的：这是一个古老且反复出现的功能请求，我在这个 bug 出现之前就拒绝了。我已经编写并支持了一些包含/排除文件语法，并决定我宁愿对 1% 的用户说“不，你不能那样做”，而不是反复说“不，你读错了文档” 20% 的用户。