当我git diff在C#文件上使用时,我看到这样的东西:
diff --git a/foo.cs b/foo.cs
index ff61664..dd8a3e3 100644
--- a/foo.cs
+++ b/foo.cs
@@ -15,6 +15,7 @@ static void Main(string[] args)
string name = Console.ReadLine();
}
Console.WriteLine("Hello {0}!", name);
+ Console.WriteLine("Goodbye");
}
}
}
hunk标题行包含当前方法(static void Main(string[] args))的第一行,这很好.然而,它似乎并不是非常可靠......我看到很多情况它不起作用.
所以我想知道,这段摘录是从哪里来的？是否git diff以某种方式识别语言的语法？有没有办法定制它？
Von*_*onC 20
有没有办法定制它？
配置在.gitattributes"定义自定义hunk-header"部分中定义:
首先,在中
.gitattributes,您将为diff路径分配属性.
*.tex diff=tex
然后,您将定义一个" diff.tex.xfuncname"配置来指定一个正则表达式,该表达式与您希望显示为"块标题" TEXT" 的行相匹配.在您的$GIT_DIR/config文件(或$HOME/.gitconfig文件)中添加一个部分,如下所示:
[diff "tex"]
xfuncname = "^(\\\\(sub)*section\\{.*)$"
注意.配置文件解析器会使用单级反斜杠,因此您需要将反斜杠加倍; 上面的模式选择一个以反斜杠开头的行,以及零或更多次出现的sub后跟section然后是open brace到行尾.
有一些内置模式可以使这更容易,并且
tex是其中之一,因此您不必在配置文件中编写上述内容(您仍需要使用属性机制启用此功能,通过.gitattributes).
(' csharp'是当前内置模式的一部分)
这段摘录来自哪里？
是否git diff以某种方式识别语言的语法？
最初,该算法对于函数名称检测非常粗略:
请参阅commit acb7257(Git 1.3.0,2006年4月,由Mark Wooding撰写)
xdiff:在hunk标题中显示函数名称.内置差异发生器的速度很好; 但显示的功能名称
diff -p是真的不错.而且我讨厌不得不选择.
所以,我们破解xdiff找到函数名称并打印它们.函数名称目前由一个特别愚蠢的算法解析:它只是试图在"旧"文件中找到一条线,从块的开始之前,其第一个字符看似合理.不过,这绝对是一个开始.
它使用get_func_line()进行了改进,它本身来自commit f258475(Git 1.5.3,2007年9月,由Junio C Hamano(gitster)撰写)
您可以在提交测试中看到t/t4018-diff-funcname.sh测试自定义diff函数名称模式.
这使得"
diff -p"hunk标头可以通过gitattributes机制自定义.
它基于Johannes早期的补丁,允许定义一个用于所有内容的正则表达式.到达用于定义hunk头的regexp的机制与其他用法相同
gitattributes.
您分配一个属性,funcname(因为"diff -p"通常使用补丁所关注的函数的名称作为hunk标头),这是一个简单的字符串值.
这可以是java要从配置文件中查找的内置模式(当前,已定义)或自定义模式名称的名称之一.
(in .gitattributes)
*.java funcname=java
*.perl funcname=perl
(in .git/config)
[funcname]
java = ... # ugly and complicated regexp to override the built-in one.
perl = ... # another ugly and complicated regexp to define a new one.
当前xfuncname语法在2008年10月Git 1.6.0.3的提交45d9414中引入,由Brandon Casey撰写
diff.*.xfuncname 它使用"扩展"正则表达式来进行大块头选择目前,'
diff -p' 生成的hunk标头可以通过diff.*.funcname在配置文件中设置选项来自定义.'funcname'选项采用基本的正则表达式.此功能是使用GNU正则表达式库设计的,默认情况下,它允许使用某些扩展正则表达式运算符的反斜杠版本,即使在基本正则表达式模式下也是如此.例如,下面的字符,反斜杠时,根据扩展的正则表达式规则的解释:?,+,和|.
因此,内置funcname模式是使用一些扩展的正则表达式运算符创建的.其他更严格遵守POSIX规范的平台不能解释基本正则表达式模式中的反向扩展RE运算符.这会导致内置funcname模式的模式匹配在这些平台上失败.
引入一个新的选项"
xfuncname"它采用扩展正则表达式,并且通告它代替的funcname.
由于大多数用户都在GNU平台上,因此大多数funcname模式都是在那里创建和测试的.
广告只xfuncname应该有助于避免创建与GNU正则表达式兼容但不在其他地方使用的非可移植模式.另外,与基本RE相比,扩展的正则表达式可能不那么难看和复杂,因为许多常见的特殊运算符不需要被反映.
例如,GNU Basic RE:
^[ ]*\\(\\(public\\|static\\).*\\)$
成为以下扩展RE:
^[ ]*((public|static).*)$
最后,由RenéScharfe撰写的git 1.7.8(2011年12月)的提交14937c2进行了扩展.
diff:添加选项以将整个函数显示为上下文添加选项
-W/--function-context来git diff.
它类似于相同的选项git grep并扩展了变化背景的上下文,以便显示整个周围的功能.
这种"自然"背景可以让更好地理解变化.
它仍然在Git 2.15(2017年第4季度)进行调整
用于检测HTML的"函数头"的内置模式与
<H1>..<H6>没有任何属性的元素不匹配,这些元素已得到修复.
在2.15之前,匹配<h1>...</h1>时未能<h1 class="smth">...</h1>匹配.
请参阅Ilya Kantor()提交9c03cac(2017年9月23日).(由Junio C Hamano合并- -在376a1da提交,2017年9月28日)iliakan
gitster