为什么执行 "git rebase" 会在暂存区和工作目录中留下相反的修改？

Question

为什么执行 "git rebase" 会在暂存区和工作目录中留下相反的修改？

9

我正在使用 git-svn 作为 svn 客户端。有时候我会遇到以下问题：

1. 我在本地的 git 分支上有几个提交，一个空的 stage 和一个干净的工作副本。 2. 在 Windows 命令行中键入“git svn rebase”以获取团队的修改并将我的提交放置在它们后面，以保持线性历史记录（这是使用 git-svn 所必需的）。 3. 一切都进行得很好，已经获取了团队的内容，并将我的提交重定位到它们后面，但是... 我最终会发现工作副本中有修改，在 stage 中有已修改的文件，并且工作副本的修改与 stage 中的修改完全相反。

我通常通过取消暂存阶段中的所有内容来解决此问题，这将还原工作副本中的修改，这很好，但我真的很想了解这里发生了什么。

问题：这是 bug 还是我对 git rebase 有什么不理解？

注意：我在使用“git svn fetch”和稍后的“git rebase”时遇到了此问题。

注意：我在 Windows 上使用 Git，使用了一个大型 SVN 存储库（10000+ 个文件，150000+ 个修订版本），我还使用了 git-extensions。我仅用它来浏览存储库和提交。其他操作都从 Windows 命令行中执行。

如此操作后，两个截图可帮助理解此问题。第一个是工作副本的内容，第二个是 stage 的内容。您可以很容易地看到两者完全相反：

enter image description here

编辑：以下是“git svn rebase”后出现问题时我的.git目录中的内容：

17/02/2012  04:57                 0 ArmuazEm5Z
05/04/2012  02:28                 0 BeMzRLwWcu
06/11/2012  14:37                90 COMMIT_EDITMSG
01/11/2012  15:42               628 config
15/02/2012  04:21                73 description
16/02/2012  13:22                 0 fuMhUevkYu
05/11/2012  15:53         1 703 279 gitk.cache
05/07/2012  03:49                 0 gJfUbdRuG9
06/11/2012  14:42                23 HEAD
11/07/2012  03:14    <DIR>          hooks
21/02/2012  03:22                 0 II5HPacSJd
06/11/2012  14:42         5 439 960 index
15/10/2012  13:18    <DIR>          info
16/02/2012  08:16                 0 jerS1GtBYS
17/02/2012  04:57                 0 Kg64sq9pzS
15/02/2012  23:36                 0 lbe0yALJYy
15/10/2012  13:17    <DIR>          logs
19/10/2012  16:58    <DIR>          objects
06/11/2012  14:42                41 ORIG_HEAD
25/10/2012  11:02             2 795 packed-refs
05/07/2012  03:49                 0 PpxYa5z0Hc
02/11/2012  10:00    <DIR>          refs
15/02/2012  23:36                 0 sm6ociDGGF
06/11/2012  14:42    <DIR>          svn
21/02/2012  03:22                 0 vEqtL0Yiqd
05/04/2012  02:28                 0 VFwn3laTEV
16/02/2012  13:22                 0 XYoiLqY5BM
16/02/2012  08:16                 0 z9vL8lRT7t
              22 File(s)      7 146 889 bytes
               6 Dir(s)  54 105 219 072 bytes free

编辑：如果您对跟踪此问题感兴趣，我已在git@vger.kernel.org邮件列表上提交了一个带有“[git-svn] [bug report] Index in strange state after git svn rebase”主题的错误报告。

- Samuel Rossille

1

嗯，你能否在不使用Git扩展的情况下从命令行重现它？另外，你一直提到“git rebase”；你是在使用“git rebase”还是“git svn rebase”（这两者有很大的区别）？ - poke

@poke 我遇到了这个问题，无论是使用 "git svn rebase" 还是 "git svn fetch" 后跟着 "git rebase"。git-extensions 经常开着，但我只用它来查看我的仓库状态和提交。我总是在 Windows 命令行窗口（而不是 git-extension shell）中输入其他命令，因为我觉得这样更方便。 - Samuel Rossille

使用gitk --all查看图形（提交和差异），您是否得到相同的结果？我对导致您所看到的提交感兴趣，如果图形指示某些内容被“删除/---”（实际上已经被“添加/+++”），则可以预期早期的提交已经“添加”了它。请尝试查找此类提交。 - prusswan

1

@prusswan 我刚刚在问题中添加了有关gitk的解释和截图。 - Samuel Rossille

你能否展示一下在出现这个问题后进行变基操作后你的.git目录的内容？ - Brian Campbell

显示剩余7条评论

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Brian Campbell · Accepted Answer

这看起来像是一个bug。如果在rebase之前，您的工作目录和索引是clean的，那么在rebase之后它们应该还是clean的；或者您应该会遇到合并冲突并有机会清理它并继续rebase。

看起来由于某种原因，在应用本地修改后，您的索引无法更新。

基本上，当前存储库状态有三个主要视图。首先是HEAD提交，即存储库自上次提交以来的状态，也是您下一次提交要建立的基础。在rebase期间，这方面已经被正确地更新了。现在HEAD是您的本地提交，重定位到了来自upstream存储库的顶部。

其次是索引，它应该包含下一次提交的预期状态。问题似乎就出在这里。从干净的树进行成功rebase后，索引应该显示与HEAD相同的存储库视图，但它似乎得到了过时的视图（即upstream存储库包含的视图）。看起来在应用本地补丁之后它没有被更新。

第三个是您的工作副本；它实际上是您磁盘上的文件。在进行rebase时，头提交正在正确更新，工作树正在正确更新（或正在保持不变），但索引是处于一个状态，它同样指向您正在rebase的源提交。这意味着，如果您将索引与重定位后的提交进行比较，它看起来像是您已经还原了更改；并且如果您将工作副本与索引进行比较，它会看起来像您已经重新添加了这些更改。

有几件事需要检查：

你能否在遇到此类问题后告诉我们你的.git目录中的内容？仅列出.git顶级文件的列表将很有帮助。实际上，完整的清单，包括文件名、修改日期和权限，可能会提供更多信息。
您是否在任何网络文件系统或其他奇怪的地方使用它？网络文件系统有时会出现文件过时的问题，我想知道是否出现了这种情况。
您正在使用哪个版本的Git？