Question

At my workplace we use SVN for version control. I switched to git-svn when I found out about it, and recently I decided to sync some of my private branches to another remote git repo. The workflow, then, consists of rebasing from and pushing to the SVN repo via git-svn, while working on separate private feature branches that are pushed to the remote git repo so I can work on them at home if necessary.

Now, every time I rebase from git-svn, my remote git repo asks to be pulled first. Sometimes, the changes don’t merge cleanly when doing a pull, even though, supposedly, the remote repo should contain the same commits that my local one that’s synced with svn. Lately I resorted to deleting the remote branches before pushing them again to the remote repo, but that can’t be right.

Is git just not set up for this sort of workflow, or am I doing something wrong?

Thank you!

Answer 1

First, thanks to Matthew for the links — they were helpful to me in coming to my own solution for this problem.

It’s possible to do this, but the caveats are that it requires some care and very probably has limits with respect to the number of committers involved. My use case is basically what mitjak describes; a single user that has a need and/or desire to utilize two remote repositories, one SVN and the other Git. In my case the former is at work behind a firewall and the other is offsite (also private). The goal is to be able to work on a local copy of the repository using Git and keep both remote repositories happy.

My procedure:

This all hinges on the fact that git svn dcommit changes the SHA1’s associated with the original git commits. With that point firmly in mind, after making a commit locally, I [optionally git svn rebase then] git svn dcommit, producing the final SHA1. At that point, I push to my remote git repo. If as Chacon states all that you want to do is provide a more efficient cloning point using git you are done. But you may also want to be able to:

1. push to the remote git repository from another local “pure git” repository, followed by
2. sync’ing the hybrid git/svn repository, and then
3. pushing those changes up to the SVN repository.

Step 1 represents no problem; following a commit to your local “pure git” repository git push to the remote git repository.

Step 2 is again no problem; back in your hybrid git/svn repository, git pull the changes from the remote git repository. At this point the SHA1’s associated with the newly pulled revisions are in sync with those in the remote git repository.

Step 3 is where the process gets a little trickier. You can git svn dcommit these changes as described above to push them up to the SVN repository, but then the situation is a bit different than that described above. In this case, you now have the same revisions in the remote SVN and git repositories, but they have different SHA1’s because of the dcommit. I handle this in the following way:

During the pull in Step 2, I note the associated beginning SHA1; e.g.,

  git pull
  [e-mail]'s 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(-)

So here the SHA1 of interest is 34b6260. git log origin should confirm that this is the last commit in the remote git repository that has a git-svn-id associated with it. I then do the following:

git push -f origin 34b6260:master

performing a forced update of the remote repository to exclude the “pure git” commits that I made from the “pure git” local repository — use with care! In this case, I know that I have these commits locally; they just have different SHA1’s from the dcommit. I then git push to the remote repository, adding the “git-svn-id”-versions of the commits that I just removed, and the remote repositories are in sync.

Re-syncing the “pure git” local repository with the remote git repository is the final step, but similar care produces satisfactory results. In this case, the remote git repository now contains the “git-svn-id”-versions of the commits, while the local “pure git” repository still contains the original SHA1s. The easiest way to deal with this is to git fetch from the remote git repository, then git reset --hard origin to force the local git repository to mirror the state of the remote.