我对Git 2.43中的--pickaxe-regex行为感到失望。diffcore文档声称如下（强调我的）：
“-S“检测前映像和后映像中出现指定文本块的次数不同的文件对。根据定义，它不会检测文件内移动。此外，当修改器在不影响感兴趣的字符串的情况下批量移动文件时，diffcore-rename会像往常一样启动，而-S忽略了文件对（因为在重命名检测到的文件对中，该字符串的出现次数没有改变）。**当与--pickaxe-regex一起使用时，将视为要匹配的扩展POSIX正则表达式，**而不是文字字符串。
但这似乎并不准确。我一直在比较Python存储库中这些测试命令的输出：
# Success: just text in the search block
git log --pickaxe-regex -S'def'
# Broken on MacOS: POSIX extended word boundaries
git log --pickaxe-regex -S'\bdef\b'
git log --pickaxe-regex -S'\<def\>'
# But success on Git for Windows字符串\b-wrapping并不要求def以单词边界开始开始和结束。它只是打破了搜索，这样就不会返回任何结果。为了防止对转义有一些困惑，我还尝试了-S'\\bdef\\b'，-S"\bdef\b"和-S"\\bdef\\b"。它们都没有返回结果，但-S'def'可以。
这是怎么回事？
2条答案
按热度按时间pkmbmrz71#
\b不是由POSIX定义的。它是Perl、Ruby和PCRE中存在的扩展。从Linux上的
regex(7)：正则表达式（regular expressions，RE），在POSIX.2中定义，有两种形式：现代的RE（大致是egrep的RE; POSIX.2称之为"扩展的" RE）和过时的RE（大致是ed（1）的RE; POSIX.2称之为"基本的" RE）。
POSIX扩展RE支持
|，+，*，?，^，$和边界（带大括号）。它们还支持带字符类的方括号。regex(7)：Objective（"基本"）正则表达式在几个方面有所不同。|"、"+"和"？'是普通字符，没有与其功能等效的字符。边界的分隔符是"{"和"}"，"{"和"}"本身是普通字符。嵌套子表达式的括号是"（"和"）"，'（'和'）'本身是普通字符。'^'是普通字符，除了RE或（!）带括号的子表达式的开头，'$'是普通字符，除了在RE或（!）一个带括号的子表达式的结尾，如果"*"出现在RE的开头或带括号的子表达式的开头，则它是普通字符（在可能的前导'^'之后）。
所有其他转义和功能基本上都是由Perl或PCRE定义的（包括普通的C转义，比如
\t和\n）。我不相信在pickaxe功能中有使用PCRE的选项，所以你需要发送一个补丁或坚持使用扩展的POSIX正则表达式。gdx19jrr2#
The answer from bk2204对于制作POSIX.2兼容的可移植脚本是正确的。然而，在 * 您的本地系统上，* 您似乎得到了操作系统决定的“扩展”正则表达式包含的任何内容，包括它捆绑的任何扩展。
请参阅
regex(7)和/或re_format(7)以了解您的配置。| 正则表达式|macOS| Git for Windows|
| --|--|--|
|
def个| ✓ | ✓ ||
\bdef\b个|| ✓ ||
\<def\>个|| ✓ ||
[[:<:]]def[[:>:]]个| ✓ |（致命）||
def[[:blank:]]个| ✓ | ✓ |