git-svn fetch isn't pulling in the latest vers

Question

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

Answer 1

I believe you want git svn rebase. This is different from git 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:

git svn rebase --local

If you have local commits that are not yet in SVN, git-svn will replay (rebase) them on top of the newest SVN commits.

Answer 2

git svn fetch only copies new revisions to your local object database, very much like git fetch – both only synchronize object databases. It will not update your branch and working copy. To get the newly fetched changes into your branch, use git svn rebase; it will re-apply all your local changes on top of the latest svn revision.

git svn rebase will do a fast-forward when there are no local commits, so it should not mess with history. Alternatively you could use git merge --ff-only git-svn to 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 reset when 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!)

Answer 3

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

Answer 4

Has the same issue here in 2018 with the latest git. Resolved by removing the .rev_map and index files and rerun git svn fetch.

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

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:master in mine case has reverting changes back before the reindex. So DO NOT DO the pulling. Make the rebase and push before the pull to propogate the fixed changes to the remote repository.