为什么樱桃选择告诉我，我所有的线路都改变了？ [英] Why does cherry-pick tell me that I have all lines changed?

问题描述

更新

考虑文件abc，在提交A和B中相同

  begin 
 123 
 456 
 789 
 klm 
 end 
  

在A中，我们重构第一行 123 => AAA 并在结果顶部选择B. Git告诉文件中的所有行已经改变。如果我们通过更新任何一行来修改B，它的差异将正常运行。 Git会注意到，在这种情况下，只有这一行文本发生了变化，如果它也是第一行，则报告单行冲突。

这里是重现的代码

  mkdir full-shit; cd full-shit 
 git init; echo rrr>根 ; git add root 
 git commit -m root 
 
 git checkout -b A; git checkout -b B 
 
函数makeABC {
 echo begin> abc 
 echo123>> abc 
 echo456>> abc 
 echo789>> abc 
 echoklm>> abc 
 echo end>> abc 
} 
 
将ABC提交到分支B 
 makeABC; git add abc; git commit -m abc 
 
 echo将为A创建一个新文件，而不是'git cherry-pick B'
 git checkout A; makeABC 
 echo'git checkout A; git cherry-pick B'可以很好地复制A = B 
 sed -i -e's / 123 / AAA / g'abc 
 git add abc; git commit -m一个重构的
 
 
回声观察!!!选中B表示A和B之间的所有行不同！ 
 echo但是如果我们选择C而不是B，则不会发生 -  git会正确地执行diff操作，abc 
 case B中的detectinc碰撞
B ）git cherry-pick B ;; 
B2）git checkout B 
 sed -i -e's / 123 / BBB / g'abc 
 git add abc; git commit -m BBB 
 git checkout A; git cherry-pick B ;; 
 esac 
 
 git gui& 
 
 echo'full-shit'文件夹创建
  

请注意，Git Gui将所有行标记为冲突，而EOL字符在两次提交中完全匹配，因为它们是在相同的运行中创建的，使用相同的代码，甚至可以使用从B到A的樱桃选择以避免文件系统操作进行精确复制。

出于这个原因，我认为，这个问题更多地与前一个，而不是通常导致类似结果的EOL。同样在这种情况下，如果我在B中的第一次提交之上添加B2更改，git开始区分单行。什么是git的逻辑？

解决方案<当你在 git-gui 历史浏览器中选择一个提交时，它显示了在提交和它的第一个父代之间发生了什么变化，在这种情况下是相同的输出为 git diff A ^ .. A 。由于分支 A 在上次提交之前没有该文件，因此diff自然会将整个文件显示为新文件。 B 在这一点上甚至没有考虑到。

当你比较两个分支头时（ git diff A..B ），你会看到 A 和 B



可以找到更多关于 git diff 的语法信息在 man git-revisions 中。

至于樱桃选秀，由于三向合并。

Updated

Consider file abc, identical in both commits A and B

begin
 123
 456
 789
 klm
end

In A, we refactor first line 123 => AAA and pick B on top of the result. Git tells that all lines in the file have changed. Its diff will operate normally however, if we modify B by updating any single line. Git will notice that only this one line of text has changed in this case, reporting a single-line conflict if it was the first line also.

Here is the code to reproduce

mkdir full-shit ; cd full-shit
git init ; echo rrr > root ; git add root
git commit -m root

git checkout -b A ; git checkout -b B

function makeABC {
    echo begin > abc
    echo " 123" >> abc
    echo " 456" >> abc
    echo " 789" >> abc
    echo " klm" >> abc
    echo end >> abc
}

echo commiting ABC into branch B
makeABC ; git add abc ; git commit -m abc

echo will make a new file for A instead of 'git cherry-pick B'
git checkout A ; makeABC
echo 'git checkout A ; git cherry-pick B' would work equally well to make copy A = B
sed -i -e 's/123/AAA/g' abc
git add abc ; git commit -m "A refactored"


echo observe that !!!PICKING B TELLS THAT ALL LINES BETWEEN A AND B ARE DIFFERENT!!!
echo whereas if we picked C instead of B this would not happen -- git would make the diff operation properly, detectinc collision at the frist line of abc
case "B" in
    "B") git cherry-pick B ;;
    "B2") git checkout B
        sed -i -e 's/123/BBB/g' abc
        git add abc ; git commit -m BBB
        git checkout A ; git cherry-pick B ;;
esac

git gui & 

echo 'full-shit' folder created

Please note that Git Gui marked all lines as conflicting whereas EOL characters totally match in both commits because they were created in the same run, by the same code and you can even use cherry-pick from B to A to avoid file system operations for exact copy.

For this reason, I believe, this issue is more related to the previous one, than to the EOL, which often causes a similar result. Likewise in that case, git starts to differentiate single lines if I add B2 change on top of first commit in B. What is the logic of git?

解决方案

When you select a commit in the git-gui history browser, it is showing what changed between that commit and its first parent, in this case the same output as git diff A^..A. Since branch A did not have this file until in its last commit, the diff naturally shows the whole file as new. B is not even considered at this point.

When you diff the two branch heads (git diff A..B) you will see the direct difference between A and B regardless of the histories of the two.

More information on the syntax used for git diff above may be found in man git-revisions.

As for the cherry-pick, it gets it right thanks to three-way merge.

这篇关于为什么樱桃选择告诉我，我所有的线路都改变了？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！