为什么“git rebase”会在舞台和工作副本中留下相反的修改集合？

我使用git-svn作为svn客户端。我不时遇到以下问题。为什么“git rebase”会在舞台和工作副本中留下相反的修改集合？

我开始在我的本地git分支提交几个提交，一个空的阶段和一个干净的工作副本。
我输入窗口的命令行“混帐SVN变基”获取球队的修改，并把我的承诺后，他们保持一个线性的历史（这是需要使用混帐SVN）
一切顺利，团队的内容被提取和我的承诺后重新分配，但...

我最终在工作副本中修改，并在舞台上修改文件，工作副本的修改是确切的反例在舞台上的修改。

我通常围绕此只是unstaging一切的舞台，而归还的工作拷贝，这是很好的修改，但我真的想了解这里发生了什么。

问题：这是一个错误，还是我用git rebase不理解的东西？

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

注意：我在带有大型svn存储库（10000+个文件，150000+修订版）的windows上使用git，并且我也使用git-extensions。 编辑：我使用它只探索存储库并提交。我从Windows命令行执行其他任何操作。

编辑：根据其中一条评论的要求，这里有两个截图帮助理解问题。第一个是工作副本的内容，第二个是舞台的内容。你可以很容易地看到两者是完全相同oposite：

工作拷贝： enter image description here

阶段（恢复工作副本的修改，很直观：相同的图像，红色和绿色被交换）： enter image description here

编辑：我只是在一个非常简单的情况下重现了这个问题：我的提交只修改一个文件，在“git svn rebase”期间提取的提交很少，并且它们都不影响修改后的文件。我查过“gitk --all”。它与git-extensions和“git status”完全相同。这里是gitk的输出。我们从底部到顶部看到：

最后3行是3次提交当绑定时提取。他们都没有触及我的文件。
第三行显示我在rebase之后的提交：它很好，它添加了它应该添加的内容，并删除了它应该删除的内容。
第二行显示的索引的内容：包含修饰恢复我的承诺
第1行显示的工作副本内容：它包含了我的承诺做同样的修改，IE恢复索引中的修改。

enter image description here

编辑：这里的内容我一个 “混帐SVN变基” 问题出在哪里发生后.git DIR：

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

编辑：如果你有兴趣在跟踪这个问题时，我在主题中报告了[email protected]邮件列表上的一个bug，其中“[git-svn] [bug report] git svn rebase之后的奇怪状态索引”。

来源

2012-11-01 Samuel Rossille

听起来像一场噩梦。无论如何摆脱SVN？ –

@AdamDymitruk这是一家500多人公司的漫长过程......我在等待更改时使用git-svn。我对此非常满意：快速创建分支，快速分支交换，多个工作副本，出色的合并功能......有时只有几个问题。 –

你可以发布gitk的截图，说明发生了什么？与分支和差异和敏感的东西消灭等我怀疑你的工作树是不干净甚至在rebase之前（你可以通过'git status'检查） – prusswan

这似乎是一个错误。如果您的工作目录和索引在重新绑定之前是干净的，那么在重新绑定之后它们应该是干净的;或者你应该得到一个合并冲突并有机会清理它并继续进行rebase。

它看起来像是由于某种原因，你的索引在应用你的本地修改后仍然是陈旧的。

基本上，存储库的当前状态有三个主要视图。有HEAD提交，它是上次提交时的存储库状态，以及您的下一个提交将作为子进程的内容。在您的重新设置期间这个更新正确。 HEAD现在是您的本地提交，根据您从上游存储库获得的内容重新进行升级。

还有一个索引，它应该包含您下一次提交的状态的视图。这似乎是问题所在。在从干净的树中成功重新绑定之后，索引应该看起来与作为HEAD的存储库具有相同的视图，但似乎获得了上游存储库包含的内容的陈旧视图。看起来它在上游存储库顶部应用本地修补程序后未更新。

还有你的工作副本;磁盘上的实际文件。出于某种原因，当你进行rebase时，head commit被正确更新，并且工作树正在被正确更新（或者被单独留下），但是索引被保留在一个指向源提交的状态你正在重新投入。这意味着如果您将索引与您的重定向提交进行比较，则看起来您已经恢复了您的更改，并且如果您将工作副本与索引进行比较，则看起来您已将其重新添加回。

有几件事情要检查：

你能告诉我们你的.git目录的内容，这样有问题的重订后？只有.git顶级文件的列表会很有帮助。实际上，完整列表包括文件名，修改日期和权限可能会提供更多信息。
你是通过任何一种网络文件系统或其他奇怪的东西来使用它吗？网络文件系统有时会存在文件过时的问题;我想知道这是否发生在你身上。
你使用的是什么版本的Git？

来源

2012-11-05 21:21:22

非常感谢您的关注。 *** 1 ***我会在下次发现问题时发帖。 *** 2 ***我的git存储库位于C：\上一个很好的旧NTFS文件系统上，但我的用户的主目录包含.gitconfig位于网络驱动器（公司计算机配置）上*** 3 *** git --version输出“git version 1.7.10.msysgit.1”我从git-extensions站点安装了一个包含git-extension和git的bundle。我不知道他们打包了自己的git版本。我刚刚意识到，一边检查版本。我会尝试安装一个常规版本的git，看看我是否仍然有这个问题。 –

@SamuelRossille Git扩展只是打包标准的Git for Windows（msysgit），所以它与一个相同，你可以手动安装。 – poke

我编辑了问题，在发生问题时添加.git目录的内容。我开始认真地认为这是一个错误，但我无法在git邮件列表中找到存档。我想我会报告它。 –

为什么“git rebase”会在舞台和工作副本中留下相反的修改集合？

回答

相关问题