【问题标题】:git stash and edited hunksgit stash 和编辑过的帅哥
【发布时间】:2011-05-02 18:48:25
【问题描述】:

我非常喜欢git add -pgit 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 处于未合并状态。请再次注意,问题只发生在手动编辑的帅哥上。如果不手动编辑任何大块,上面的命令没有任何问题。

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

【问题讨论】:

  • 我尝试了好几次,但我无法用 git 版本 1.7.2.3 重现您的问题。你用的是什么版本?
  • 我在 Mac OS X 上使用的是 1.7.3.1 版本。
  • git add -p 中使用不同的随机编辑再次尝试——它对我来说总是很好。顺便说一句,我在 Linux 上。听起来像一个错误——我建议在 git 邮件列表中询问,他们的响应速度非常快。
  • 根据邮件列表,这不是错误,而是预期的行为。不过我不明白为什么......
  • 弗兰克的回答解决了问题。

标签: git conflict git-stash git-add


【解决方案1】:

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

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

【讨论】:

  • 这如何解释 git 认为只有在我有手动编辑的块时才存在冲突
  • 因为 git stash pop 时索引不匹配。
  • @Scott:抱歉,我不明白你的答案... :-/ 为什么只有在手动编辑块时才会发生冲突?
  • @Olivier - 请参阅上面 Sven 的评论:值得在 git 列表中询问您是否发现了错误。
【解决方案2】:

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

这是我得到的答案:

如果您没有手动编辑大块,每个大块将要么在 状态 HEAD 或状态 A,并将 HEAD 和 A 之间的差异应用于 这样的文件要么是无操作(已经应用了大块),要么是 申请成功。

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

【讨论】:

  • 看起来问题在于,当您执行“git stash --keep-index”时,它会同时存储分阶段和未分阶段的更改,唯一的区别是它保留了工作副本中的分阶段更改。当您尝试应用存储时,分阶段的更改既在工作副本中,也在导致冲突的存储中。在他们回答的未编辑大块的情况下,它会记住哪些大块存在于工作副本中,哪些不存在也不适用曾经存在的避免合并冲突。对于一个编辑过的帅哥,只有一部分应用它不能做到这一点。
【解决方案3】:

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

git add --patch <files>

git stash --keep-index

<test the indexed changes>

git reset --hard

git stash pop --index

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

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

【讨论】:

  • +1,这行得通。我自己也采用了相同的解决方案,但错过了 --index 开关。考虑到它同时存储索引和未暂存的更改,这是一种合乎逻辑的做事方式,因此为了避免工作副本中的暂存更改和隐藏的更改之间的合并冲突,必须首先从工作副本中删除这些更改(即硬重置)。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 2017-03-18
  • 2016-06-18
  • 2017-11-25
  • 2013-02-23
  • 2014-03-11
  • 2012-09-10
相关资源
最近更新 更多