为什么"git rebase"会在舞台和工作副本中留下相反的修改？
Sam*_*lle 9 svn git git-svn git-rebase git-stage
我正在使用git-svn作为svn客户端.我不时会遇到以下问题.
我从我当地的git分支中的几个提交开始,一个空的阶段和一个干净的工作副本.
我在windows命令行中输入"git svn rebase"来获取团队的修改并在我们之后提交我的提交以保持线性历史记录(这是使用git-svn所必需的)
一切顺利,团队的内容被提取,然后我的提交被重新定位,但......
我最终修改了工作副本,并修改了阶段中的文件,并且工作副本的修改是阶段中修改的完全相反.
我通常只是通过解除阶段中的所有内容来解决这个问题,这会恢复工作副本中的修改,这很好,但我真的很想了解这里发生了什么.
问题:这是一个错误,还是我用git rebase无法理解的东西？
注意:我在以后使用"git svn fetch"和"git rebase"时遇到了问题.
注意:我在带有大型svn存储库的Windows上使用git(10000多个文件,150000+版本),我也使用git-extensions.编辑:我用它只探索存储库并提交.我从windows命令行做了其他事情.
编辑:根据其中一条评论的要求,这里有两个截图,以帮助理解问题.第一个是工作副本的内容,第二个是舞台的内容.您可以很容易地看到两者都是完全相反的:
工作副本:
舞台(恢复工作副本修改,非常直观:相同的图像,红色和绿色交换):
编辑:我只是在一个非常简单的情况下重现了这个问题:我的提交仅修改了一个文件,在"git svn rebase"期间提取的提交非常少,并且它们都没有影响修改后的文件.我查了一下"gitk --all".它与git-extensions和"git status"完全相同.这是gitk的输出.我们从下到上看:
- 最后3行是在重新定位时获取的3次提交.它们都没有触及我的文件.
- 从顶部开始的第3行显示我在rebase之后的提交:它都很好,它添加了它应该添加的内容并删除它应该删除的内容.
- 第二行显示索引的内容:它包含恢复我的提交的修改
- 第一行显示工作副本的内容:它包含与我的提交相同的修改,IE恢复索引中的修改.
编辑:这是我的.git目录的内容后发生问题的"git svn rebase":
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] [错误报告]索引处于git svn rebase之后的奇怪状态".
这似乎是一个错误。如果你的工作目录和索引在变基之前是干净的，那么它们在变基之后也应该是干净的；或者你应该得到一个合并冲突并有机会清理它并继续变基。
看起来由于某种原因，您的索引在应用本地修改后就变得陈旧了。
基本上，存储库当前状态有三个主要视图。HEAD 提交是最后一次提交时存储库的状态，也是您的下一次提交的子提交。在您的 rebase 过程中，这会被正确更新；HEAD 现在是您的本地提交，基于您从上游存储库获得的内容进行重新构建。
有索引，它应该包含下一次提交的状态的视图。这似乎就是问题所在。从干净的树成功变基后，索引应该具有与 HEAD 相同的存储库视图，但它似乎获得了上游存储库包含的陈旧视图。在上游存储库上应用本地补丁后，它似乎没有更新。
这是你的工作副本；磁盘上的实际文件。由于某种原因，当您进行变基时，头提交正在正确更新，工作树也正在正确更新（或保持不变），但索引仍处于引用原始提交的状态你正在重新定位。这意味着，如果您将索引与重新基址提交进行比较，则看起来您已经恢复了更改，而如果您将工作副本与索引进行比较，则看起来您已将它们再次添加回来。
有几件事需要检查：
.git在这样有问题的变基之后，您能向我们展示您的目录内容吗？只需列出顶层的文件列表.git就会很有帮助。实际上，完整的列表（包括文件名、修改日期和权限）可能会提供更多信息。- 您是否在任何类型的网络文件系统上使用它，或者其他奇怪的东西？网络文件系统有时会出现文件过时的问题；我想知道你是否也遇到过这种情况。
- 您使用什么版本的 Git？