混帐存储和编辑的人 [英] git stash and edited hunks

问题描述

我完全喜欢 git add -p 和 git stash 但我偶尔会遇到以下问题通过以下命令序列：

• git add -p my_file ：然后我手动编辑一个hunk （使用 e ），因为该混帐暗示不适合我


• git stash --keep-index ：然后我做一些测试，如果测试通过我不承诺

现在问题发生了：文件 my_file 现在被认为是冲突 / strong>，并且git已经完全搞乱了我的编辑过的hunk，所以我必须编辑文件，删除无用的合并标记，然后运行 git add my_file ，然后加上 git reset HEAD

我很困惑，因为只有在手动编辑hunk 。我不明白这应该如何改变。

---

重现问题：

• touch newfile


• git添加新文件


• git commit -m'newfile'


• 在文件中添加两行


• git add -p newfile
编辑大块（ e ），删除hunk中的一行，然后退出git add（ q ）

• git stash --keep-index


• git stash pop
  
  现在文件 newfile 处于未合并状态。请再次注意，问题仅出现在手动编辑的hunk中。如果不手动编辑任何hunk，则不会有任何问题。
  
  
  

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

  ）
  

  解决方案

  我在git邮件列表中问了这个问题，我描述的是预期的行为。 。： - （

  
  
  

  这是我得到的答案：
  
  

  
  

  如果你没有手动编辑hunk，每个hunk都将在
  状态HEAD或状态A中，并且将HEAD和A之间的差异应用到
  这样的文件将是一个无操作（已经应用了Hunk ）或
  的成功应用程序。

  
  

  对我来说，这是一个严重的限制 git add --patch ，并且我不明白这种行为对于任何人都有用，但我会学会接受它。

  
  

  I totally love git add -p and git stash but I occasionally have the following problem, which is reproduced by the following sequence of commands:

  • git add -p my_file: then I edit a hunk manually (using e) because the splitting that git suggests does not suit me
  • git stash --keep-index: then I do some testing, and if the tests pass I do not commit
  • git stash pop: now the problem occurs: the file my_file is now considered as conflicted, and git has completely messed with my edited hunk, so I have to edit the file, remove the useless merge marks, and run git add my_file followed by git reset HEAD

  I'm puzzled because this happens only when editing a hunk manually. I don't see how this should make any difference at all.

  ---

  To reproduce the problem:

  • touch newfile
  • git add newfile
  • git commit -m 'newfile'
  • add two lines in the file
  • git add -p newfile
  • edit the hunk (e), remove one of the line in the hunk, then quit git add (q)
  • git stash --keep-index
  • git stash pop

  Now the file newfile is in unmerged state. Note, again, that the problem only occurs with manually edited hunks. There is no problem whatsoever with the commands above if one does not edit any hunk manually.

  Incidentally, the preceding state of the file is in the third stage (git show :3:newfile), and the previously staged version is in the second stage (git show :2:newfile). So I could, by some git black magic, manage to put the second stage in this index, and the third stage in the working repo... but I don't know how to do that so I do it by hand. :-(

  解决方案

  I asked the question in the git mailing list. What I describe is the expected behaviour. It's not a bug. :-(

  Here is the answer I got:

  If you did not edit the hunk manually, each hunk will be either in state HEAD or in state A, and applying the diff between HEAD and A to such file will be either a no-op (hunk already applied), or a successfull application.

  For me this is a severe limitation of git add --patch, and I don't understand in what way this behaviour may be useful to anyone, but I will learn to live with it.

  这篇关于混帐存储和编辑的人的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！