git checkout --merge <tree-ish> - <paths>无法按预期工作</paths> </tree-ish>

Question

当我尝试将我的工作树更改合并到tree-ish处的文件时，通过检查其路径，前面的更改会被后面的更改覆盖。

我没想到会出现这种情况。相反，我希望Git用默认，合并或 diff3 样式中显示的冲突标记替换文件内容，具体取决于{{1 } {}，--merge或--conflict=merge选项已提供给--conflict=diff3。

鉴于以下用例：

git checkout

我丢失了使用git init echo foo > foobar git add foobar git commit --message=blabla foobar echo bar > foobar git checkout --conflict=diff3 HEAD -- foobar 进行的本地更改。

另外，为什么手册页echo bar > foobar会在概要git-checkout(1)中提及-m和--conflict=<style>选项？这两个选项的目的是什么？

我在Microsoft Windows 7上使用git version 1.9.4.msysgit.2。

Answer 1

我明白为什么你期望这种行为 - 当你描述你正在获得的行为时，文档会说“在检查索引中的路径时”，这看起来像是一个doc bug。请注意，在描述您想要的行为时，它会显示“切换分支时”。我完全按照你的方式阅读了那对，并以同样的方式感到惊讶。

我认为，为了准确地描述它现在正在做什么，文档应该只是说“在检查路径时”并且丢失“从索引”部分，但我也会争论你想要什么，“当检查从提交或树[无论是否指定路径]“合并行为将是一个更好的选择，并且它应该更改为以这种方式工作 - 一个更容易证明自己的课程的课程实际上并没有说明它将要做什么

Answer 2

这应该随着Git 2.22（2019年第二季度）改变。

“ git checkout -m <other>”是关于在签出另一个分支的同时将HEAD和工作树文件之间的差异向前传送，而忽略了HEAD和索引之间的差异。

已指导该命令在索引和 HEAD不一样。

请参见commit 6eff409的commit 3e41485，commit b165fac，commit 191e9d2，Nguyễn Thái Ngọc Duy (pclouds)（2019年3月22日）。
^{（由Junio C Hamano -- gitster --在commit 4a3ed2b中合并，2019年4月25日）}

  

checkout：防止丢失--merge中的分段更改

     

指定--merge时，我们可能需要进行真正的合并（而不是   三向树解压缩），最好在git-checkout.sh中看到这些步骤   删除之前的版本：

    # Match the index to the working tree, and do a three-way.
    git diff-files --name-only | git update-index --remove --stdin &&
    work=`git write-tree` &&
    git read-tree $v --reset -u $new || exit

    git merge-recursive $old -- $new $work

    # Do not register the cleanly merged paths in the index yet.
    # this is not a real merge before committing, but just carrying
    # the working tree changes along.
    unmerged=`git ls-files -u`
    git read-tree $v --reset $new
    case "$unmerged" in
    '')     ;;
    *)
            (
                    z40=0000000000000000000000000000000000000000
                    echo "$unmerged" |
                    sed -e 's/^[0-7]* [0-9a-f]* /'"0 $z40 /"
                    echo "$unmerged"
            ) | git update-index --index-info
            ;;
    esac

  

请注意最后的“ read-tree --reset”步骤。
  在合并合并递归将工作树弄乱之后，我们将工作树恢复回“新”树。
  如果在执行整个命令序列之前进行了阶段性更改，则它们   之所以丢失，是因为它们不太可能恢复“新”树的一部分。

     

没有简单的方法可以解决此问题。 Elijah may have something up his sleeves，但在此之前，请检查是否有阶段性的更改，   拒绝奔跑并失去他们。用户将需要执行“ git reset”   在这种情况下继续。