5

我有一组调试实用程序位于 git stash 插槽中；我在分支之间移动，这些分支在存储变化方面仅略有不同。我git stash apply在相应分支的顶部存储以测试功能。

但是我在其中一个分支中遇到了适当的合并冲突，但我想更喜欢存储中的内容，所以我希望合并策略“递归”更喜欢来自存储的版本（我猜那是“他们的”，参见man git-merge第节MERGE-STRATEGIES，小节recursive）。

我能以某种方式告诉git stash apply使用什么合并策略吗？

4

3 回答 3

14

是的，您可以自己进行合并。存储提交名为stash.

git cherry-pick -n -m1 -Xtheirs stash

Cherrypick 以cherrypick 的父级为基础进行合并。存储提交记录了具有两个父级的工作树状态，签出提交和存储索引。

告诉cherrypick 使用第-m1一个父级作为合并基础，因为这里对于您想要合并的确切更改存在任何歧义。-n说不提交结果。

这将生成一个工作树和索引，其中的更改与隐藏的工作树中的更改相匹配。相反，如果您想在隐藏索引中应用更改，请改为使用cherrypick stash^2；或者，如果您想将隐藏索引（即添加的 aka 暂存 aka 索引内容）的更改应用到隐藏的工作树，请使用-m2而不是-m1.

如果您只想合并到工作树，请执行

savetree=`git write-tree`
git cherry-pick -n -m1 -Xtheirs stash
git read-tree $savetree

这足以处理此处问题中的情况（应用一组方便的更改），但它并不能完全重现 stash 为您所做的一切。仅将隐藏的索引更改应用于当前索引，而将隐藏的工作树更改仅应用于当前工作树只是简单的挑剔。 如果有人想看到它，它git stash是一个脚本。/usr/libexec/git-core/git-stash

于 2013-10-11T23:43:52.760 回答
3

不，不修改stash脚本（您会在git-core目录中找到它）。

我不会这样做，而是将存储库变成一个真正的分支。这将：git stash branch newbranch [stash-id]

  • 检查 stash 的提交
  • git checkout -b newbranch
  • apply --index和（成功时，应该总是）drop藏匿处。

git stash save（如果您想将其作为存储区保留，则可以通过 -ing 立即恢复该存储区，然后git stash apply --index将其在新分支上重新生效。）

此时，您可以根据需要/希望提交索引和/或提交新的工作目录，和/或在新分支上大惊小怪，然后您就有了一个可以合并的“真正的分支”。

于 2013-10-11T18:44:02.320 回答
0

我遇到了同样的问题，最终使用了一个带有临时分支的复杂过程。IMO，如果 stash 命令将 -X 参数传递给 merge 命令，则可以轻松解决此问题。认为这是一个丑陋的解决方法。

净效果：将 stash 应用到当前 master，丢弃任何有利于 stash 中的差异。

  1. 按照@torek 的建议，为存储创建一个临时分支。

    git stash branch tmp [stash-id]

  2. 检查您的更改。使用任何消息，因为此提交不会是永久性的。

    git add --all .
git commit -m 'tmp commit'

  3. tmp使用“我们的”合并策略将分支重新定位到您的目的地

    git rebase -X ours master

  4. 重置临时提交，将更改添加到当前索引

    git reset HEAD^

  5. 清理临时分支

    git checkout master
git branch -d tmp

当 stash 和 master 都包含一些相同的更改时（例如，如果合作者和您都重命名文件），这会非常方便。

于 2014-05-02T14:26:41.397 回答