13

我非常喜欢git add -p，git stash但我偶尔会遇到以下问题，通过以下命令序列重现：

  • git add -p my_file：然后我手动（使用e）编辑一个大块，因为 git 建议的拆分不适合我
  • git stash --keep-index: 然后我做一些测试，如果测试通过了我不提交
  • git stash pop：现在问题出现了：文件my_file 现在被认为是冲突的，git已经完全弄乱了我编辑的大块，所以我必须编辑文件，删除无用的合并标记，然后git add my_file运行git reset HEAD

我很困惑，因为这只发生在手动编辑大块时。我不明白这应该有什么不同。

要重现问题：

  • touch newfile
  • git add newfile
  • git commit -m 'newfile'
  • 在文件中添加两行
  • git add -p newfile
  • 编辑大块（e），删除大块中的一行，然后退出 git add（q）
  • git stash --keep-index
  • git stash pop

现在文件newfile处于未合并状态。请再次注意，该问题仅发生在手动编辑的 hunks中。如果不手动编辑任何大块，则上述命令没有任何问题。

顺便提一下，文件的先前状态处于第三阶段（git show :3:newfile），而先前阶段的版本处于第二阶段（git show :2:newfile）。所以我可以通过一些 git 黑魔法，设法将第二阶段放在这个索引中，将第三阶段放在工作回购中......但我不知道该怎么做，所以我手动做。:-(

4

3 回答 3

9

要创建和测试包含部分工作树更改（包括手动编辑的块）的索引，请执行以下操作：

git add --patch <files>

git stash --keep-index

<test the indexed changes>

git reset --hard

git stash pop --index

此时没有冲突，存储库、索引和工作目录处于紧接git stash. 您现在可以git commit进行索引更改。

当然，这很奇怪，也不是很直观，我真的很想知道是否有更简单的方法来做到这一点。

于 2011-03-14T16:37:03.057 回答
4

我在 git 邮件列表中问了这个问题。我描述的是预期的行为。这不是一个错误。:-(

这是我得到的答案：

如果您没有手动编辑大块，则每个大块将处于 HEAD 状态或状态 A，并且将 HEAD 和 A 之间的差异应用于此类文件将是无操作（已应用大块）或成功应用.

对我来说，这是一个严重的限制git add --patch，我不明白这种行为对任何人有什么用处，但我会学会忍受它。

于 2010-11-03T11:14:06.813 回答
2

git stash --keep-index保留您的索引，但它仍将索引内容添加为存储的一部分。

尝试git stash save -p- 保存存储有点乏味，但可能会做你想做的事。

于 2010-10-31T01:58:20.530 回答