tags:

views:

232

answers:

4

Hello,

I would like to use Git for my own purpose and I must use Subversion repository in my company. I know that there is 'git svn' command but it requires lineral history also in git repository. The problem with that is that I would like: - to synchronize git repository with another my git repository on my remote disk so that I can synchronize it with another git repository on different computer, - and the most important: I would like to commit frequently in my git repository and when I decide that this small steps are worth to commit (big enough to share) I would like to commit them to svn but with only one commit... So I wouldn't like to show all my git (mayby sometimes stupid, too small commits just to remember something) in svn, - and with 'git svn' I cannot use branches (because when I merge them with master, master will not have lineral history).

Please help... Maybe there is some workflow in which I can use git in it's full glory and svn to commit bigger (not my 'private'... maybe very small changes and which for some time casue that cod doesn't compile) changes to my company repository.

Thanks in advance!

+7  A: 

I would like to synchronize git repository with another my git repository on my remote disk so that I can synchronize it with another git repository on different computer.

Try:

git remote add external-repo ssh://host/path/to/git/repo.git
git push origin external-repo

I would like to commit frequently in my git repository and when I decide that this small steps are worth to commit (big enough to share) I would like to commit them to svn but with only one commit.

No sweat. Collapse multiple commits with git rebase -i (this is called "squashing") and decide whether you want to keep, throw away, or squash each commit into a larger one. It's very helpful for getting organized before pushing to an external repo. The -i is for "interactive" mode.

with 'git svn' I cannot use branches (because when I merge them with master, master will not have lineral history).

That's not true. Just set up a branch on git for each branch you want to track with svn. In the opposite direction, you're only pushing one branch at a time anyway.

John Feminella
+2  A: 

I work this way all the time at my company (really just can't stand subversion anymore). What makes you think you can't use branches with git svn? Not only can you use them, you can commit from them directly back to subversion.

To do the merging of commits you'd use something like git rebase remotes/trunk --interactive and squash commits together. However you can't maintain both your expanded version and your condensed versions at the same time. You either get all the little tiny commits or you get the squashed ones.

Jason Punyon
is there a videocast showing this workflow? this sounds like something I d like to try, Cheers
Miau
Thanks for quick answer. But what if I would like to have detailed history form my own in git and as a consequence I do not what to squash commits? Branches... Can I have only my (not shared in svn) branches? As I am concerned I cannot merge my branch with master and then do in master git svn... because master will not have linear history. What is Yours best practice to work personally with git and with svn in company? Could You show your's workflow by example commands?
miki
@miki: Re Branches - yes those (not shared in svn) were the ones I was talking about. You can make as many branches as you like and merge them back to master before dcommitting back to svn. Or you can dcommit straight from those branches back to svn.
Jason Punyon
+2  A: 

Instead of interactive rebase you can also use git merge --squash on the “official” branch.

git checkout master
git merge --squash development

This has the advantage that it won’t destroy your development history. You can now create a large commit containing all your changes, or you can reset the index (using git reset) and use git add -p or git gui to create any number of separate commits from your branch which you would then commit normally to master and git-svn dcommit them when appropriate.

Bombe
A: 

What I do (and the easiest way to do this) is to not attempt to manage two methods of source control at once. I use git for my own personal version control. A few times a week, when i'm ready to commit to the central repository, I check out the master branch in git and commit it to TFS. Changes from the server are checked out into my dev branch and merged back into my code.

It isn't elegant, by any means, but since I'm only checkout/checkin from the central repo a few times a week, it works perfectly well.

kubi