git-svn fetch не тянет в последних версиях

Question

Когда я выполняю

git svn fetch

из моего репозитория, он ничего не возвращает и не обновляет даже при наличии новых коммитов под свн.

[root]# svn log -l 1  http://example.com/trunk/client-resources/resource-pa
    r12958 | ing | 2011-08-22 18:29:57 -0500 (Mon, 22 Aug 2011) | 1 line
    SRGENERAL-1468 adding more arrays for pa
[root]# git-svn fetch
[root]# git log -1
    commit be19ae4c7d1a3c3da6dd90389aebd6d76792cc71
    Author: sltin <sltin@44b83e5a-25ef-0310-8dbe-ee0aa4f92a64>
    Date:   Wed Jun 22 14:30:53 2011 +0000

    Fixing the classpath.

    git-svn-id: http://example.com/trunk/client-resources/resource-common@12406 44b83e5a-25ef-0310-8dbe-ee0aa4f92a64

Обратите внимание на различия версий. Журнал SVN перечисляет 12958, а журнал Git перечисляет последние версия SVN как 12406.

Я могу сделать сброс до 12406, а затем произвести новую выборку:

[root]# git svn reset 12406
    r12406 = be19ae4c7d1a3c3da6dd90389aebd6d76792cc71 (refs/remotes/git-svn)
[root]# git svn fetch
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12977 = 1b21f560b0354b28fe1a272d7723b1e6fa90a99c (refs/remotes/git-svn)
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12978 = bf22ea0151a364eb1ca1af37a7a907d5b5cc7420 (refs/remotes/git-svn)
        M       src/test/java/csl/resource/ioc/AbstractResourceIocTest.java
    r12987 = ce922c2eae07f6c12dbbd4175a9c61055b563ee3 (refs/remotes/git-svn)

И когда я проверяю версии журнала, они остаются неизменными.

Как заставить git-svn извлекать последние версии из svn?

Edit:

Я нашел ответ, данные svn загружаются в неактивный поток, который обычно объединяется с активной веткой, которой нет в пустом хранилище. Я попытался сделать сброс, но для этого тоже нужна активная ветка. Окончательный ответ был:

git reset --soft refs/remotes/git-svn

Answer 1

git svn fetch копирует только новые ревизии в вашу локальную объектную базу данных, очень похоже на git fetch - обе синхронизируют только объектные базы данных.Он не обновит вашу ветку и рабочую копию.Чтобы получить недавно полученные изменения в вашу ветку, используйте git svn rebase;он будет повторно применять все ваши локальные изменения поверх последней версии SVN.

git svn rebase выполнит ускоренную перемотку вперед, когда нет локальных коммитов, поэтому он не должен связываться с историей.В качестве альтернативы вы можете использовать git merge --ff-only git-svn для быстрой перемотки к самой последней редакции SVN (и прервать, если она не ускорена, т.е. не является прямым потомком)

Вы должны использовать git svn reset только в восходящем SVNизменил историю (svndump / svnadmin), и вам необходимо повторно получить новые коммиты, но это почти никогда не должно происходить (в противном случае обвините администратора!)

Answer 2

Я нашел ответ: данные svn загружаются в неактивный поток, который обычно объединяется с активной веткой, которой нет в пустом хранилище. Я попытался сделать сброс, но для этого тоже нужна активная ветка. Окончательный ответ был:

git reset --soft refs/remotes/git-svn

Answer 3

Я верю, что вы хотите git svn rebase.Это отличается от git pull, но схоже тем, что оба включают два шага (выборка с удаленного компьютера, а затем перебазирование или объединение).

Вы также можете перебазировать только уже извлеченные коммиты:

git svn rebase --local

Если у вас есть локальные коммиты, которых еще нет в SVN, git-svn воспроизведет (перебазирует) их поверх новейших SVN-коммитов.

Answer 4

Имеет ту же проблему здесь, в 2018 году, с последней версией git.Решено путем удаления файлов .rev_map и index и повторного запуска git svn fetch.

/.git/svn/refs/remotes/origin/trunk/.rev_map.<GUID>
/.git/svn/refs/remotes/origin/trunk/index

Каким-то образом он застрял при неправильной привязке последней редакции SVN в кэше.В моем случае это была ревизия r32, которая на самом деле была ревизией r31 (потому что r32 и r31 имеют явно разные сообщения фиксации, вот как я это обнаружил), и она показывала ревизию r32 с сообщением фиксации из ревизии r31.

Внимание:

Обнаружена другая проблема.* git pull origin trunk:master в моем случае имеет возвращающиеся изменения до переиндексации.Так что не делайте тяги.Сделайте rebase и push перед pull, чтобы распространить фиксированные изменения в удаленном хранилище.