git stash和编辑的帅哥

Oli*_*ier 12 git conflict git-stash git-add

我非常喜欢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
  • 编辑hunk(e),删除hunk 中的一行,然后退出git add(q)
  • git stash --keep-index
  • git stash pop

现在文件newfile处于未合并状态.请注意,问题只发生在手动编辑的帅哥身上.如果没有手动编辑任何块,上面的命令没有任何问题.

顺便提一下,文件的先前状态在第三阶段(git show :3:newfile),而先前阶段的版本在第二阶段(git show :2:newfile).所以我可以通过一些git black magic设法将第二阶段放在这个索引中,并将第三阶段放在工作回购中......但我不知道如何做到这一点,所以我手工完成.:-(

fra*_*ank 7

要创建和测试包含部分工作树更改的索引(包括手动编辑的数据库),请执行以下操作:

git add --patch <files>

git stash --keep-index

<test the indexed changes>

git reset --hard

git stash pop --index
Run Code Online (Sandbox Code Playgroud)

此时没有冲突,存储库,索引和工作目录处于紧接之前的状态git stash.您现在可以git commit进行索引更改.

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


Oli*_*ier 4

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

这是我得到的答案:

如果您没有手动编辑该块,则每个块将处于状态 HEAD 或状态 A,并且将 HEAD 和 A 之间的差异应用于此类文件将要么是无操作(块已经应用),要么是成功的应用程序。

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