git diff的/ a / b前缀是什么原因?

我一直在使用git了好几年了,总是想知道为什么git diff会用/和b /作为前缀名。 我预计最终会偶然发现一个有用的用例,但直到现在,它总是令人讨厌,从来没有帮助。

到底有什么好处呢? 为什么默认启用? 在哪些情况下有用?

正如差异手册页所述 ,a / et b /表示区分源和目的地的前缀。

其实,你可以select:

--no-prefix 

不要显示任何来源或目的地前缀。

 --src-prefix=<prefix> 

显示给定的源前缀而不是“a /”。

 --dst-prefix=<prefix> 

显示给定的目标前缀而不是“b /”

如果您觉得没有用处,可以closures它:

 git config --global diff.noprefix true 

这些目录前缀基本上是为了兼容性,并作为一个合理的默认select。 解释如下。

在git之前

在git(和其他VCS )之前,为多个文件创build补丁的工作stream可能是如下所示:

  • 假设您在目录asdf-source.latest中有一个项目asdf的源代码。
  • 你把目录复制到一个新的目录(例如asdf-source.new ,理想的是硬连接里面的文件)。
  • 现在,您可以在asdf-source.new进行所有更改,尝试编译代码,testing代码等。
  • 完成后,使用例如diff -r asdf-source.latest asdf-source.new >new_feature.patch创build一个补丁。 产出也随着时间演变。 除了其他的东西,git默认使用“统一”输出,这可能是使用diff的-u参数获得的。

现在,您可以看到该修补程序有使用目录名称更改文件的path。

那么应用你的补丁的人(或者构build脚本等)将会使用patch而不是使用git apply或者git am 。 为了使命令find正确的文件,必须使用patch的-pN选项(N显示要删除的目录名称和分隔符的数量)从path中删除目录名称。 在上述情况下,使用的命令可能是patch -p1 <new_feature.patch 。 这使得修补程序创build者可以使用他/她自己的目录名称。

如果您遇到使用大量补丁修补某个项目的脚本(通常用于Linux发行版中的稳定版本的后端端口修补程序),则修补程序可能会有所不同。 patch命令能够正确地检测这些格式,但是对于path有多难(需要删除多less个目录)。 有些问题:

  • 强迫开发人员使用0目录不是很好。
  • patch查找文件可能是危险的(因为它可能会发现一个不同的文件)。

所以每个人发送可以用patch -p1应用的patch -p1似乎是最明智的方法。

回到混帐

当创buildgit时,它会采用合理的默认设置(与大多数项目的提交准则兼容,主要是内核),以供select。 多亏了这个,你可以使用git,并将正确格式的补丁发送给使用patch人,反之亦然(git也能够处理diff -created补丁)。 具有“a”和“b”作为前缀特别节省空间(以及极小的带宽百分比),同时保持所有的工作。

你可以将git config diff.mnemonicprefix true设置为git config diff.mnemonicprefix true ,以便git使用不同的前缀,具体取决于你正在比较的内容(更多细节参见git help config )。

这是区分来源和目的地。 您也可以将其更改为更有意义的:

–src-prefix = <prefix>

 Show the given source prefix instead of "a/". 

–dst-prefix = <prefix>

 Show the given destination prefix instead of "b/". 

http://git-scm.com/docs/git-diff

如果您想手动添加git diff --no-prefix到您的.gitconfig ,只需添加以下内容:

 [diff] noprefix = true