git-svn fetch 未提取最新版本
当我执行
git svn 获取
从我的存储库中，它不会返回任何内容，并且即使有新的提交也不会更新 在 svn 下。
[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 获取最新版本？
编辑：
我找到了答案，svn 数据被加载到一个非活动线程中，该线程通常会合并到活动分支中，而活动分支不存在于裸存储库中。我尝试重置，但这也需要一个活动分支。最终的答案是：
git reset --soft refs/remotes/git-svn
When I execute a
git svn fetch
from my repository, it returns nothing and doesn't update even though there are new commits
under svn.
[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
Note the version differences. The svn log lists 12958 and the git log lists the latest
svn version as 12406.
I can do a reset to 12406 and then a new fetch:
[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)
And when I check the log versions, they are unchanged.
How do I get git-svn to pull in the latest versions from svn?
Edit:
I found the answer, the svn data is loaded in to an inactive thread that would normally be merged in to the active branch, which doesn't exist in a bare repository. I tried to do a reset, but that needs an active branch too. The final answer was:
git reset --soft refs/remotes/git-svn
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
git svn fetch仅将新修订版本复制到本地对象数据库，非常类似于git fetch– 两者都仅同步对象数据库。它不会更新您的分支和工作副本。要将新获取的更改添加到您的分支中，请使用 git svn rebase ；它将在最新的 svn 修订版之上重新应用所有本地更改。当没有本地提交时，
git svn rebase将进行快进，因此它不应该弄乱历史记录。或者，您可以使用 git merge --ff-only git-svn 快进到最新的 svn 修订版（并在不可快进时中止，即不是直接后代）您应该仅当上游 svn 更改历史记录（svndump / svnadmin）并且您需要重新获取新提交时才使用 git svn Reset ，但这几乎不应该发生（否则归咎于 行政！）
git svn fetchonly copies new revisions to your local object database, very much likegit fetch– both only synchronize object databases. It will not update your branch and working copy. To get the newly fetched changes into your branch, usegit svn rebase; it will re-apply all your local changes on top of the latest svn revision.git svn rebasewill do a fast-forward when there are no local commits, so it should not mess with history. Alternatively you could usegit merge --ff-only git-svnto fast-forward to the most recent svn revision (and abort when it is not fast-forwardable, i.e. not a direct descendant)You should only use
git svn resetwhen upstream svn has changed history (svndump/svnadmin) and you need to re-fetch the new commits, but this should almost never happen (otherwise blame the admin!)我找到了答案，svn 数据被加载到一个非活动线程中，该线程通常会合并到活动分支中，而活动分支不存在于裸存储库中。我尝试重置，但这也需要一个活动分支。最终的答案是：
I found the answer, the svn data is loaded in to an inactive thread that would normally be merged in to the active branch, which doesn't exist in a bare repository. I tried to do a reset, but that needs an active branch too. The final answer was:
我相信你想要 git svn rebase 。这与 git pull 不同，但相似之处在于两者都涉及两个步骤（从远程获取，然后重新设置基准或合并）。
您还可以仅对已获取的提交进行变基：
如果您有尚未在 SVN 中的本地提交，git-svn 将在最新的 SVN 提交之上重放（变基）它们。
I believe you want
git svn rebase. This is different fromgit pull, but similar in that both involve two steps (fetch from remote and then rebase or merge).You can also rebase only already fetched commits:
If you have local commits that are not yet in SVN, git-svn will replay (rebase) them on top of the newest SVN commits.
2018 年最新的 git 也有同样的问题。通过删除
.rev_map和index文件并重新运行git svn fetch来解决。不知何故，它被困在缓存中不正确的最后一个 svn 修订关联上。在我的例子中，它是 r32 修订版，实际上是 r31 修订版（因为 r32 和 r31 具有明显不同的提交消息，这就是我检测到的方式），并且它一直显示 r32 修订版和 r31 修订版的提交消息。
警告：
发现了另一个问题。在我的例子中， git pull origin trunk:master 已将更改恢复到重新索引之前。所以不要拉动。在
pull之前进行rebase和push，以将固定更改传播到远程存储库。Has the same issue here in 2018 with the latest git. Resolved by removing the
.rev_mapandindexfiles and rerungit svn fetch.Somehow it has been stuck on incorrect last svn revision association in the cache. In mine case it was the r32 revision which actually was the r31 revision (because r32 and r31 has clearly different commit messages, this is how i detected that) and it has been showing r32 revision with the commit message from the r31 revision.
Caution:
Has catched another problem. The
git pull origin trunk:masterin mine case has reverting changes back before the reindex. So DO NOT DO the pulling. Make therebaseandpushbefore thepullto propogate the fixed changes to the remote repository.