Question

我有一个git-svn存储库（Unexpected merge error in a git svn system?）;除了引用SVN仓库的origingit之外，它还有一个名为git-svn的远程引用另一个git仓库。

$ git branch -a
* master
  remotes/git-svn
$ git remote show 
origingit
$ tree .git/refs/{heads,remotes}
.git/refs/heads
└── master
.git/refs/remotes
├── git-svn
└── origingit

问题在于：当我做的时候

git pull --rebase origingit master

... git拆分树，以便原始git svn clone中所有来自origingit的提交都会丢失git-svn-id（＆＃34; local＆＃34 ;，见git-svn-id is missing from some commits）;在这种情况下，相关的提交看起来像这样（它们都有＆＃34; null编辑＆＃34;在名称中）：

$ git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order | grep 'null edit'
* cae158d (git-svn) : null edit A06
* 8f79edf : null edit A05
* 0c7373e : null edit A04
* b4bf336 : null edit A03
* e05cfc6 : null edit A02
| * e0c6823 (HEAD, master) : null edit A07
| * 03ed433 : null edit A06
| * de3bd53 : null edit A05
| * 65bf738 : null edit A04
| * 62ab3f6 : null edit A03
* | 964b300 : null edit A01
| * 14f5aba : null edit A02
| * f0ef194 : null edit A01

请注意master已经选择了最新的＆＃34; null编辑A07＆＃34;，它来自origingit。

当我这样做时

git svn rebase

... SVN存储库中存在的所有提交应该获得git-svn-id，而尚未提交给SVN的那些提交不会 - 但是在（按时间或按顺序排列）之后列出git-svn-id中的git log个;所以在下一个git svn dcommit，那些本地人将被投入SVN。但是，在这种特殊情况下，我将log --graph视为：

* cae158d (HEAD, git-svn, master) : null edit A06
* 8f79edf : null edit A05
* 0c7373e : null edit A04
* b4bf336 : null edit A03
* e05cfc6 : null edit A02
* 964b300 : null edit A01

事实上，这里git svn rebase输出到stdout只是＆＃34;首先，倒带头重播你的工作......＆＃34;并退出;否则，通常会说＆＃34;申请：......＆＃34;这显然是指补丁（并且......是那些本地的提交消息），在这种情况下，预期的日志将是：

* xxxxxxx (HEAD, master) : null edit A07
* cae158d (git-svn) : null edit A06
* 8f79edf : null edit A05
* 0c7373e : null edit A04
* b4bf336 : null edit A03
* e05cfc6 : null edit A02
* 964b300 : null edit A01

所以 - 即使null edit A07显然是origingit repo中的有效提交，并且在null edit A06之后（也存在于SVN中），git svn rebase无法应用此修补程序。为什么 - 甚至怎么可能？

在任何情况下，从这一点开始，我可以git pull --rebase ...并进入前面显示的状态。

如果有一些调试工具可以告诉你git rebase如何通过每次提交并决定做什么，那将是非常好的 - 但不幸的是，--verbose只是转储文件列表在最后一个git-svn-id提交和最新的HEAD之间进行了更改，因此它没有多大帮助。

向/usr/lib/git-core/git-svn添加一些打印输出，我发现git svn rebase最终会调用git rebase refs/remotes/git-svn;所以我试着给它添加互动：

$ git pull --rebase origingit master
...
$ git rebase --interactive  refs/remotes/git-svn

......它显示：

noop

# Rebase cae158d..e0c6823 onto cae158d
#
# Commands: [...]

因此，在rebase期间不应用补丁，因为它没有发现应该制作任何补丁。但是这怎么可能 - 注意到cae158d是＆＃34;空的编辑A06＆＃34;在git-svn内（并且在SVN和origingit中都存在），而e0c6823是＆＃34;空的编辑A07＆＃34;来自origingit的 - 在＃34; null编辑A06＆＃34; ??

之后，它在默认情况下毫无疑问且没有问题作为提交（意思是，必须有来自先前版本的实际更改）

那么，我怎样才能检查为什么会发生这种情况 - 最终，我怎样才能强制git在git svn rebase期间识别那里确实存在补丁呢？

调试为什么git（svn）rebase不检测补丁（noop）？

0 个答案: