How to deal with Git-svn when have to use both Git and Subversion

Question

[Update]

For more details, The reason that why I try to do pure Git at home is that, my company would like to move to Git but manager won't like to make change because developer don't have knowledge with Git on our own repository. So, what I try to do is, I try to make everyone use Pure git while someone can merge back to Subversion during this learning phase. So, in any emergency case, they can still using Subversion.

So, before everyone familar with Git, I cannot transfer repository to use pure Git. So, it will have both update on Subversion and Git. (and Main repository right now is Subversion). So, I try to make the way that Git can working smoothly during I have sync repository by dcommit back to Subversion.

[Question]

I am in the organization which use Subversion as repository, so I dump it as my personal Git (and plan to use replace Subversion with Git in the future)

Now, I have repository that use both Git and Subversion (Main Source) . I have a problem to deal with git svn rebase when I have to use both git and subversion.

My Workflow is like below

At Office

1. The Repository have Git-svn interface
2. I always commit the code to Subversion with git svn dcommit from here.
3. I push to my remote git repository at Bitbucket

At Home

1. I clone the repository from Bitbucket
2. Working with and commit to Bitbucket

Now, Back to OFfice

1. git pull
2. git svn rebase
3. git svn dcommit
4. git push

In step 4. I have a problem that I already rebased my branch

Problem now here, when I am back home

When I come back home, I cannot use 'git fetch' because the branch is already rebased. So, I have to remove branch with git branch -D ..... and then git checkout again.

So, I look for the way that we can concurrent use both Git repository and Subversion and do going well with Git after done operation with git svn rebase or git svn dcommit .

Note. I won't prefer to use any git-svn at home. Try to move forward to use only Git.

Answer 1

Okay, your main problem here seems to be that you can't really do a git pull from home has the history has been rewritten (actually it should work but it would try to do an unnecessary merge).

The easiest way to get past that issue would be using git pull --rebase . This way, instead of merging the commits you've made at home with the tip of your remote branch, you rebase every commits done since your branch creation on the tip of the branch. Git will be smart enough to see that some commits are exactly the sames and they will be automatically be pruned during the rebase.

Answer 2

I assume the main cause of your problem is that git svn dcommit changes the commit message to include the SVN commit data. As the message is included in the SHA1 of a commit this change appears to git as a totally different commit.

My solution for that would be to have one branch at your office repo which you sync with SVN and another (purely git) branch to do your work in. Whenever you want to exchange something with the SVN repo you do a merge in one or the other direction.

In my case I've set up another git repo dedicated solely for SVN exchange. I have a cron job which syncs that repo every 15 minutes with the SVN server. This way I don't miss a git svn rebase .

Answer 3

You didn't mention why you are keeping svn after all. But my recommendation is to start with a clean git repo, once and for all. And avoid not necessary problems.

I believe is Casey who made the best answer on migrating to git: How to migrate SVN repository with history to a new Git repository?

Of course you have to make a backup and then start the process.

Another idea is that if the rebase is the problem, why not use a pure svn update, and then commit the changes to Git (git commit only), as if you wrote it yourself.

Answer 4

Actually you should be able to git fetch but instead of merging with git merge origin/branch you can use git rebase origin/branch . That should fix your problem

If it doesn't help try git fetch then git checkout -f -B branch origin/branch the last command would force overwrite on local branch from the remote branch.

Answer 5

Found the solution from Version Control with Git book. Page 295.

Instead of use local - master branch, have to checkout remote branch

git checkout remote/master (Detach HEAD)
git merge --no-ff master (merge the local master)
git svn dcommit
git push origin (update to git Repository)

This model is for one person who will merge back to Subversion repository while the other work on pure Git OR pure Subversion. With this way, The Git Users can use Git without Merging problem.