Ответ 1
Во-первых, благодаря Мэтью за ссылки - они были полезны для меня, когда я пришел к собственному решению этой проблемы.
Это можно сделать, но оговорки состоят в том, что это требует некоторой осторожности и, вероятно, имеет ограничения по количеству вовлеченных коммиттеров. Мой вариант использования - это в основном то, что описывает митьяк; один пользователь, который имеет потребность и/или хочет использовать два удаленных репозитория, один SVN и другой Git. В моем случае первый работает за брандмауэром, а другой - вне компании (также частный). Цель состоит в том, чтобы иметь возможность работать с локальной копией репозитория с помощью Git и поддерживать оба удаленных репозитория счастливыми.
Моя процедура:
Все это зависит от того, что git svn dcommit изменяет SHA1, связанный с оригинальной записью Git. С этой точки зрения, после совершения локального совершения, я [опционально git svn rebase then] git svn dcommit, создавая окончательный SHA1. В этот момент я подталкиваю к удаленному репозиторию Git. Если в качестве Chacon указано все, что вы хотите сделать, это обеспечить более эффективную точку клонирования, используя Git. Но вы также можете захотеть:
- нажмите на удаленный репозиторий Git из другого локального репозитория "pure git", а затем
- синхронизация гибридного репозитория git/svn, а затем
- перетаскивание этих изменений в репозиторий SVN.
Шаг 1 не представляет проблемы; после фиксации в локальном "чистом git" репозитории git push в удаленном репозитории Git.
Шаг 2 снова не проблема; обратно в ваш гибридный репозиторий git/svn, git pull изменения из удаленного репозитория Git. На этом этапе SHA1, связанный с недавно выведенными ревизиями, синхронизируется с репозиториями в удаленном репозитории Git.
Шаг 3 - это процесс, который немного сложнее. Вы можете git svn dcommit изменить эти изменения, как описано выше, чтобы подтолкнуть их к репозиторию SVN, но тогда ситуация немного отличается от описанной выше. В этом случае у вас теперь есть те же ревизии в удаленных хранилищах SVN и Git, но они имеют разные SHA1 из-за dcommit. Я обрабатываю это следующим образом:
Во время вытягивания на шаге 2 я отмечаю ассоциированное начало SHA1; например.
git pull [email protected] password: remote: Counting objects: 5, done. remote: Compressing objects: 100% (3/3), done. remote: Total 3 (delta 0), reused 0 (delta 0) Unpacking objects: 100% (3/3), done. From ssh://example.org/pub/scm/demonstrate 34b6260..17cd887 master -> origin/master Updating 34b6260..17cd887 Fast forward file3 | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Итак, здесь SHA1 представляет интерес 34b6260. git log origin должен подтвердить, что это последний фиксатор в удаленном репозитории Git, который имеет связанный с ним git -svn-id. Затем я делаю следующее:
git push -f origin 34b6260:master
выполнение принудительного обновления удаленного репозитория для исключения "чистого git" означает, что я сделал из "чистого git" локального репозитория - используйте с осторожностью! В этом случае я знаю, что у меня эти локальные локали; у них просто есть SHA1 из dcommit. Затем я git push удаленный репозиторий, добавляя "git -svn-id" -версии коммитов, которые я только что удалил, и удаленные репозитории находятся в синхронизации.
Повторная синхронизация локального репозитория "pure git" с удаленным репозиторием Git является последним этапом, но подобный уход дает удовлетворительные результаты. В этом случае удаленный репозиторий Git теперь содержит "git -svn-id" -версии коммитов, тогда как локальный "чистый git" репозиторий по-прежнему содержит исходные SHA1. Самый простой способ справиться с этим - git fetch из удаленного репозитория Git, затем git reset --hard origin, чтобы локальный репозиторий Git отображал состояние удаленного.