git svn rebase пропускает/теряет фиксации (на rebase -continue из-за конфликта слияния)?

Question

У меня есть проблема с отсутствующими фиксаций, в установке очень похож на описанный в Unexpected merge error in a git svn system? (нажмите для полного размера):

К сожалению, я не могу воспроизвести эту проблему в качестве примера, так что я Я попытаюсь предоставить информацию, которая, по моему мнению, имеет значение. Я работаю локально в myrepo_git_wc и поэтому он представляет собой «исходный источник»; В настоящее время он имеет это состояние нескольких последних коммитов (все из которых имеют «нулевой редактировать» в названии, так что я после этого оглавлению):

$ git log --graph --decorate --pretty=oneline --abbrev-commit --all --date-order | grep 'null edit' 

* 03ed433 (HEAD, master) : damnit, null edit again 
* de3bd53 (origin/master, origin/HEAD) : previous null edit passed 
* 65bf738 : again null edit - no improvement 
* 62ab3f6 : still bad; trying again w null edit 
* 14f5aba : another null edit; previous was bad 
* f0ef194 : null edit - starter 

Я толкаю мою работу здесь, чтобы myrepo_git_LS.git голой репо; который затем с помощью крюка post-update обновляет myrepo_gitsvn, что в конечном счете dcommit s до myrepo_svn_WS.

Таким образом, на данный момент, myrepo_git_LS.git показывает следующее (с той же git log --graph... команды, как указано выше):

* 03ed433 (HEAD, master) : damnit, null edit again 
* de3bd53 : previous null edit passed 
* 65bf738 : again null edit - no improvement 
* 62ab3f6 : still bad; trying again w null edit 
* 14f5aba : another null edit; previous was bad 
* f0ef194 : null edit - starter 

Так, myrepo_git_LS.git имеет те же фиксаций, как myrepo_git_wc, как и ожидалось - до сих пор так хорошо.

Сначала myrepo_gitsvn показывает это для git log --graph ...

* 964b300 (HEAD, git-svn, master) : null edit - starter 

Так myrepo_gitsvn находится на самой старой «нулевой» редактировать фиксации (хотя хэш не совпадает); который является тем же самым изменением, где находится myrepo_svn_WS. Я хотел бы добавить новые коммиты в myrepo_gitsvn репо тоже - так, от myrepo_gitsvn, я:

git pull --rebase origingit master 

... который должен тянуть в фиксаций от myrepo_git_LS.git. Теперь myrepo_gitsvn показывает это git log --graph...:

* 03ed433 (HEAD, master) : damnit, null edit again 
* de3bd53 : previous null edit passed 
* 65bf738 : again null edit - no improvement 
* 62ab3f6 : still bad; trying again w null edit 
| * 964b300 (git-svn) : null edit - starter 
... 
* | 14f5aba : another null edit; previous was bad 
* | f0ef194 : null edit - starter 
... 

Это своего рода странно, что здесь я получаю самый старый «нулевой редактировать - стартер» совершить дважды; здесь также показаны исходные SHA. На этом этапе дерево графов показано как разделенное (т. Е. Git и SVN-коммиты показаны отдельно).

Итак, я думаю, если я буду здесь git svn rebase (как я обычно делаю в своем рабочем процессе, с которым у меня раньше не было проблем), то репо сможет «сжать» эти коммиты.К сожалению --verbose не раскрывает здесь много деталей, но это выход при выполнении этой команды в myrepo_gitsvn:

$ git svn rebase 
user@ssh.server's password: 
First, rewinding head to replay your work on top of it... 
Applying: : still bad; trying again w null edit 
Using index info to reconstruct a base tree... 
Falling back to patching base and 3-way merge... 
Auto-merging folder/file.tex 
CONFLICT (content): Merge conflict in folder/file.tex 
Failed to merge in the changes. 
Patch failed at 0001 : still bad; trying again w null edit 

When you have resolved this problem run "git rebase --continue". 
If you would prefer to skip this patch, instead run "git rebase --skip". 
To check out the original branch and stop rebasing run "git rebase --abort". 

rebase refs/remotes/git-svn: command returned error: 1 

Поскольку он говорит, что не удалось в «по-прежнему плохо, пытаясь снова ж нулевому редактировать», который commit 62ab3f6 - я просто проверяю эту ревизию файла (хотя то же самое происходит, если я вручную отредактирую файл в текстовом редакторе); а затем попросить rebase к --continue в myrepo_gitsvn:

$ git checkout 62ab3f6 folder/file.tex 
$ git add folder/file.tex 
$ git rebase --continue 
Applying: : still bad; trying again w null edit 
Applying: : again null edit - no improvement 
Applying: : previous null edit passed 
Applying: : damnit, null edit again 

Это выглядит почти хорошо; но если я делаю команду git log --graph ... сейчас в myrepo_gitsvn, я получаю:

* eef9e50 (HEAD, master) : damnit, null edit again 
* 9b2af2d : previous null edit passed 
* 380b0f9 : again null edit - no improvement 
* a41db2b : still bad; trying again w null edit 
* 964b300 (git-svn) : null edit - starter 

Если сравнивать с первоначальным состоянием - помимо совершения SHA хэшей не быть тем же самым, есть еще одна проблема: совершить "другой пустой редактировать, предыдущая была плохая «(который должен быть между» нулевой редактирования - стартер «и» по-прежнему плохо, пытаясь снова ж нулевому редактировать «) является нет больше !!? В принципе, я мог бы git svn dcommit это состояние сейчас - и он будет загружен на сервер SVN без ошибок; но я бы потерял один из коммитов, что впоследствии может вызвать проблемы во время перезагрузки!

Таким образом, на данный момент я удаляю последние коммиты в myrepo_gitsvn путем сброса, как это:

git reset --hard 964b300 
git svn reset -r446 
git svn rebase 

... который приносит о государстве, с которым начал этот пост (и поэтому я могу цикл с этой процедурой на неопределенный срок).

Мой вопрос: что я могу сделать, поэтому все коммиты, представленные первоначально в git-стороне, распознаются и интегрируются также стороной svn; или, другими словами, как я могу заставить git svn также получить эту потерянную/отсутствующую фиксацию?

Answer 1

Всего несколько нот; похоже, это связано с «null edit - starter« commit присутствует в два раза. Как я понимаю, в раскол дерева графика:

• | * указывало бы git-svn совершить, то есть один с «SVN» SHA хэш
• * сверху указывают на «простой мерзавец» совершает, которые имеют только git SHA hash
• и * | указывают на фиксацию с хэшем git SHA - но тот, который, по-видимому, уже присутствует в SVN!

Это означает, что * | 14f5aba : another null edit; previous was bad будет означать, что какой-то образом, ГИТ-SVN получил информацию, что этот был присутствует в SVN - и все же это было Р 447 «нуля редактирования - стартер» был обороты 446 - и глава СВН был 446.

Но - это было 446, потому что в предыдущих попытках, я попытался Manually deleting only the latest revision from online SVN repository? - и, по-видимому, было государство, где 447 был также в дереве SVN и так git- svn как-то записал это.

На этом этапе я попытался сначала Remove specific commit - 14f5aba один, но это не сработало; по-видимому, эта привязка между git и SVN фиксируется в другом месте. Так что я сделал, чтобы «подделка» совершить ревизию 447 на SVN (поскольку у меня уже была исходная git одной и той же ревизии, я мог бы сделать один и тот же патч и одно и то же сообщение commit, в результате чего был бы тот же git-хэш) и что позволило окончательно найти фиксацию при следующей перезагрузке. Но потом я столкнулся с другими проблемами с тем же репо ... Итак, в конечном счете, я не уверен, что это все, что есть ...