9

我使用 git-svn 作为 svn 客户端。我不时遇到以下问题。

  1. 我从本地 git 分支中的几个提交开始，一个空的阶段和一个干净的工作副本。

  2. 我在 Windows 命令行中键入“git svn rebase”以获取团队的修改并将我的提交放在他们之后以保持线性历史记录（这是使用 git-svn 所必需的）

  3. 一切顺利，团队的内容被获取，然后我的提交被重新设置，但是......

    我最终在工作副本中进行了修改，并且在阶段中修改了文件，并且工作副本的修改与阶段中的修改完全相反。

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

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

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

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

编辑：根据评论之一的要求，这里有两个屏幕截图可以帮助理解问题。第一个是工作副本的内容，第二个是阶段的内容。您可以很容易地看到两者是完全相反的：

工作副本： 在此处输入图像描述

阶段（还原工作副本修改，非常直观：相同的图像，红色和绿色交换）： 在此处输入图像描述

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

  • 最后 3 行是变基时获取的 3 个提交。他们都没有碰我的文件。
  • 顶部的第 3 行显示了我在 rebase 后的提交：一切都很好，它添加了应该添加的内容并删除了应该删除的内容。
  • 第 2 行显示索引的内容：它包含恢复我的提交的修改
  • 第一行显示了工作副本的内容：它包含与我的提交相同的修改，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 后索引处于奇怪状态”。

4

1 回答 1

3

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

看起来由于某种原因，您的索引在应用本地修改后变得陈旧。

基本上，存储库当前状态的三个主要视图。有 HEAD 提交，它是最后一次提交时存储库的状态，以及您的下一次提交将是什么的子项。这在你的 rebase 期间被正确更新；HEAD 现在是您的本地提交，基于您从上游存储库获得的内容。

有一个索引，它应该包含下一次提交状态的视图。这似乎是问题所在。在从干净的树成功变基后，索引应该看起来与 HEAD 具有相同的存储库视图，但它似乎正在获取上游存储库包含的内容的陈旧视图。在上游存储库之上应用本地补丁后，它似乎没有更新。

还有你的工作副本；磁盘上的实际文件。出于某种原因，当您进行变基时，头部提交正在正确更新，工作树正在正确更新（或被单独保留），但索引处于引用原始提交的状态你正在重新定位。这意味着，如果您将索引与重新定位的提交进行比较，看起来您已经恢复了您的更改，如果您将您的工作副本与您的索引进行比较，看起来您又重新添加了它们。

需要检查的几件事：

  1. .git在这样一个有问题的 rebase 之后，你能告诉我们你的目录的内容吗？只是顶级文件的列表.git会很有帮助。实际上，包括文件名、修改日期和权限在内的完整列表可能会提供更多信息。
  2. 您是在任何类型的网络文件系统上使用它，还是在其他任何奇怪的东西上使用它？网络文件系统有时会出现文件过时的问题；我想知道这是否发生在你身上。
  3. 你使用的是什么版本的 Git？
于 2012-11-05T21:21:22.657 回答