git-svn: reset tracking for master

I’m using git-svn to work with an SVN repository. My working copies have been created using git svn clone -s so that my working copy follows the default directory scheme for SVN (trunk, tags, branches).

Recently I’ve been working on a branch which was created using git-svn branch myremotebranch and checked-out using git checkout --track -b mybranch myremotebranch. I needed to work from multiple locations, so from the branch I git-svn dcommit-ed files to the SVN repository quite regularly.

  • Is there any specific syntax to refer to forward commits (without using it's SHA1)?
  • How do you use the Ubuntu command line to pull a project that's been uploaded onto Git?
  • git push update issue
  • git status of another remote
  • Error while pushing to github repo
  • Create a branch from master with removed code
  • After finishing my changes, I switched back to the master and executed a merge, committed the merge, and tried to dcommit the successful merge to the remote trunk.

    It seems as though after the merge the remote tracking for the master has switched to the branch I was working on:

    # git checkout master
    # git merge mybranch
    ... (successful)
    # git add .
    # git commit -m '...'
    # git svn dcommit
    Committing to ...

    Is there a way I can update the master so that it’s following remotes/trunk as before the merge?

    I’m using git, if that’s any help.

    It would be useful if you could also explain why this happened, so I can avoid the problem happening again. Thanks!


    Here is my current .git/config:

        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
        autocrlf = false
    [svn-remote "svn"]
        url =
        fetch = trunk:refs/remotes/trunk
        branches = branches/*:refs/remotes/*
        tags = tags/*:refs/remotes/tags/*
    [branch "mybranch"]
        remote = .
        merge = refs/remotes/myremotebranch

    So it seems that the trunk is pointing to the correct place. However, switching to the branch then back to the master doesn’t help; git svn dcommit in the master still tries to push to myremotebranch.

  • Dissapearing Git Repository in eGit
  • git post-receive hook can not jump back into original cwd
  • In Git, how to commit file once, but ignore further changes to the file
  • Git-tf unable to find required JAR
  • Migrating a TFS repository to git
  • How can I add a new file to my Git repository?
  • 6 Solutions collect form web for “git-svn: reset tracking for master”

    When there are no changes on trunk, git does a fast-forward merge and simply sets the local “master” branch to the commit on your branch. Git-svn doesn’t know how to commit fast-forward merges back to trunk, in fact it thinks “master” now is pointing to the svn branch.

    To work around this, use git merge --no-ff when merging. This will force git to create a merge commit, which can then be dcommitted to svn.

    If you git svn rebase after switching back to master and use –squash you can avoid this.

    # git checkout master
    # git svn rebase   //(<--the missing step)
    # git merge --squash mybranch // (<-- doesn't commit, more like an svn merge would do)
    ... (successful)
    # git add . 
    # git commit -m '...' 
    # git svn dcommit
    Committing to

    To solve the current state (i.e. your master is pointing to an SVN branch)

    You can ‘switch’ to another branch, delete master, ‘switch’ back to it and then merge again:

    # git checkout mybranch
    # git branch -D master
    # git checkout -b master trunk
    ... continue with merge...
    # git merge --squash mybranch

    … you now have mybranch merged into master and ready to commit and then dcommit to trunk

    If you haven’t made any commit on master, that means the git merge mybranch was a fast-forward one: master HEAD simply move to mybranch HEAD.

    That could explain why the git svn dcommit pushed your changes to the SVN mybranch.
    It would:

    • first update the corresponding SVN branch with the last Git mybranch commits not yet dcommitted,
    • record the merge to trunk on the SVN side
    • and then it would rebase master on the Git side (nothing to do, already there).

    I don’t think master hasn’t change its reference, but if you have a doubt (and your working directory is clean), you could (if master is currently checked out):

    git reset --hard remotes/trunk

    In general, you should not use git merge with git svn, because svn, even with branches, doesn’t support the kind of merge tracking that git does. When you need to merge a branch, I’ve had the most success (at least with recent svn) doing a plain svn checkout/merge process and then using git svn rebase to update my git-svn repositories. This preserves svn’s native merge tracking metadata, which (AFAIK) git-svn is completely ignorant of.

    I’m not totally sure what state your svn repository is in — I would check to make sure the merge dcommit did what you wanted it to on the trunk. Even if it did,
    I bet if you look at the contents of the refs/heads/master and refs/remotes/trunk files in your repo, you’ll see that they’re different at the moment. If that’s the case, I would (with no local changes present) do a git-svn fetch followed by a git branch -f master remotes/trunk; git reset --hard master to resync the git branch with the git-svn tracking branch. If you have local changes, you’ll have to commit and do something like git rebase master^4 --onto remotes/trunk, where 4 is the number of commits you need to preserve. Alternatively, if they’re all uncommitted, stash them with git stash first.

    Failing that, you can always get everything into svn and just wipe the repo and get a fresh checkout.

    We have successfully used git merge --squash in git-svn feature branch development. The problem with git-svn is that while your local git-svn clone can store the merge information, once you dcommit to the svn repository, it is lost.

    So for other (git-)svn users the merge commits look just like plain commits. The squash is good for the same thing as git merge --no-ff (eg. producing a merge commit on master), but it also includes a list of the actual commits made in the branch being merged, which would otherwise be lost when dcommitting.

    I had the same problem, and I merged remotes/trunk back into master after which git svn info pointed back to trunk

    I didn’t have the time to actuall dcommit as I was leaving the project and my git-svn repo died with my worstation. I did trythe dcommit –dry-run and it said it would commit back to trunk.

    I’ll reproduce the setup and test when I get the time


    Git Baby is a git and github fan, let's start git clone.