views:

228

answers:

2

I'm in a position where I'm the only one using git, everybody else is using svn. I've used 'git svn' to connect to the team svn and mostly it works just fine. Lately, I've started a project initially on my own, separate git repo and now I need to merge stuff from it to the svn. However, I still would like to keep tweaking the implementation in my own privacy between releases.

So, what would be the most straightforward way to cherry-pick some commits from my private repo to the svn-cloned repo? Requirement is to keep full local history and have only one svn commit for each pick. Or is there some squashing to be done?

As a method to achieve this, is there a way to get the private repo as another origin for the svn-cloned repo?

+1  A: 

You could try to git graft the commit from your Git repo to the commit of the git-svn repo before git dcommit the git svn repo.

The commit from your repo could be isolated in a special branch, when all kind of squashing can take place in order to export a cleaner history.

VonC
A: 

If you're the only person using the git repo at the moment, you could consider rebasing all your work on top of the empty subversion clone you've created. Then set up a branch to hold your pushes back to subversion, squash each release onto it and commit it back to SVN.

For a more in-depth solution, consider using git commit-tree directly -- provide it with the tree you want to commit (found by running git show --format=raw HEAD and looking at the second line ("tree")), the correct parent commit (whatever's currently in subversion) and the right log message on stdin. This is using the plumbing directly, you probably want to write a script to do it for you... The effect is that you've created a new commit containing the file contents of an existing commit (compare with cherry-pick, which takes the diff added by an existing commit, rather than copying the tree).

Andrew Aylett
Yes, I'm the only git user for now. Would rebasing implicate that all future work will be done in the cloned svn? The cloned svn repo is nothing but empty... Although, that may not change anything.So, in short, I could rephrase that my project is actually a subproject to be merged to a single trunk containing multiple related projects in their own directories.
Jawa
There's no reason to do the work in the repo that's been directly cloned from subversion, but you'd want to work on branches which have the subversion clone as their parent. You could achieve this by pulling the rebased branches back into your work repository and using `git branch -f` to set your current working branches to point at your rebased references.
Andrew Aylett