git push上图像旁边的%是多少?

时间:2018-11-02 19:31:40

标签: git github

我一直想知道当您进行git push时,图像重写旁边的百分比是什么意思

示例:

rewrite assets/img/30_credits.png (70%)

我一直认为它只是显示了Image画布中有多少被重写,尽管我很想知道。

很抱歉这个愚蠢的问题:) 谢谢!

1 个答案:

答案 0 :(得分:1)

简短的回答:这是Git的相似度索引。有关计算相似性的算法的详细说明,请参见Trying to understand `git diff` and `git mv` rename detection mechanism

更长:这实际上不是git push;您从git pull看到了这一点。但是它也不是git pull:它是git pull运行git merge的结果,实际上是git diff --stat打印出来的。 1 git diff --stat的打印内容是: 2

verb path (percentage)

其中 verb renamerewritecopy path 之一是相同或(对于重命名)新旧路径名的文件路径名或缩写版本,而 percentage 是相似性索引。 Git使用此相似性索引来确定两个名称不同的文件或两个名称相同但内容完全不同的文件实际上可能是 same 文件还是 different 文件毕竟。

也就是说,假设提交ba3c046中包含文件A1.txtA2.txt,提交50fcdab中包含A2.txtB1.txt (并且两个提交都没有其他文件)。 很有可能 –理所当然–即使内容有所更改,这两个A2.txt文件也是“相同”文件。也许有人签出了提交ba3c046并修改了文件,然后根据修改后的结果进行了提交50fcdab

但是A1.txtB1.txt呢?也许有人签出了ba3c046,对其进行了重命名(更改或未更改),并提交了50fcdab。如果这样做,则提交50fcdab的{​​{1}}与提交B1.txt的{​​{1}}实际上是同一文件。

Git确定这两个文件是否真正相同或“几乎相同”(重命名并稍作更改)文件的方式是比较它们的相似性。为此,它计算ba3c046A1.txt之间的相似性索引。

现在假设我们正在比较提交A1.txt(及其两个文件)与提交B1.txt,提交ba3c046具有0f3ac31A2.txtB1.txt 。每次提交时,Git都无关紧要。 Git将查看C1.txt中的内容,并对它们与A1.txt的{​​{1}} 0f3ac31的{​​{1}}的相似性进行评分。如果文件足够相似,Git将对其进行匹配。 Git将选择与B1.txt中的0f3ac31最相似的C1.txt文件。

此过程-通过文件内容的匹配程度来匹配文件-是Git如何确定0f3ac31编辑的两次提交中哪些文件“相同”。我在此过程中一直使用的术语是识别文件,我不太喜欢它,因为我们没有试图找到 100%的文件>相同(由于Git的内部存储系统,虽然可以帮助 lot )。

默认情况下,即使名称不同,即使名称相同,也会自动识别两个不同提交中的两个文件(称为“同一文件”)。也就是说,这两个文件是预先配对的,而不是因为计算出的相似性而配对。在这种情况下,它们的相似性索引会相对较差,Git会称其为“重写”。

Git也有一个相异性索引概念,它只是100减去相似度:例如,文件中75%相似的文件是25%相似的文件。 A1.txt的{​​{1}}(中断配对)标志可用于中断Git默认假设的自动配对,该默认假设是在左侧提交中路径为 P 的文件必须与右侧提交中路径为 P 的文件相同。不过,运行ba3c046会调用git diff而不设置中断标志。

计算相似度非常昂贵,因此仅对未配对的文件或在-B -B-B git diff-C git merge-查找副本git diff下完成– find-copies-harder`选项,Git会认为某些左侧/源文件可能已经被复制到某些右侧/目标文件,因此可以将源文件配对带有目标端文件的文件不会将源文件从“源”池中删除。对于差异较大的两个侧面包含大量文件的大型存储库,这需要进行大量相似度计算,并且可能会花费大量时间。


1 您还可以从. The unpaired files are those without a partner on the other side initially, or those broken-apart by获取相似性索引。我认为. If you use the的diffstat输出现在已直接内置到or本身中,但是对于真正的合并,您可以通过运行or来重复它。

对于快进操作(即使git apply进行合并,这实际上不是合并),您需要指定正确的提交对。在git merge之后,分别是git mergegit diff --stat <merge>^1 <merge>,因此git merge可以解决问题,但是由于它们是相对名称,因此它们将在一段时间后停止工作。) ,一些外壳程序(例如Windows上的PowerShell,以及Linux上的tcsh和zsh)使得提供git pull后缀变得更加困难,因为他们喜欢出于自己的目的使用HEAD@{1}语法。

2 有几种格式。例如,HEAD的输出使用代码字母和百分比,而不是单词。不过,这些都是用不同的方式表达相同的意思:Git已在左侧和右侧提交中对某些文件进行了配对,尽管这些文件的内容有所更改。