#How I use Git-SVN
I've just realised that all my git and git-svn posts are on the Atlassian Extranet and thus lost to me. So here's a quick re-write of one of them, for Mike Cravey. Please feel free to fork and add your own recommendations or suggestions:
I've never used TortoiseGit and I barely remember Windows CLI (do they still call it DOS?) commands, but you know OSX shizzlit so I'll just write it as I know it and you can translate ;)
I like to clone the whole repo, branches, tags and all. If you're in a rush, do this anyway, then check out just the branch you need right now somewhere else. I find it saves heaps of time and hassle later if you're set up right.
git svn clone http://svn.example.com/project -T trunk -b branches -t tags
Make sure you're checking out the SVN root, not /trunk
Folks always tell me you can use -s or --stdlayout to replace the flags at the end there, but I have never ever had it work for me and you can waste an awful lot of time checking out a repo only to find it's only got trunk and have to start again.
From master I create a working branch (usually for the issue number I'm working)
(master) $ git co -b work-52
do some work...
(work-52) $ git ci -a -m "awesome commit message"
(work-52) $ git co master
Grab the latest from SVN: (master) $ git svn rebase
Rebase my work into master: (master) $ git rebase work-52
This keeps my history neat, with only commits for work (as much as possible) - otherwise, SVN takes the merge as the first line of the commit message and that's crap for reading your history in SVN browsing tools etc later. (and must REALLY suck for your colleagues who are still on SVN)
Push to SVN: (master) $ git svn dcommit
Delete the working branch (even if we're going straight back) (master) $ git br -D work-52 (master) $ git co -b work-52
The deletion means not having to rebase back. It also means you don't end up with a lot of one-shot local branches hanging around.
That's the simplest, and I've found best, way to work with git-svn. Don't ever commit in master. Things can get messy really quick if someone has committed conflicting changes.
If it's a particularly fast-moving project (or phase) and you pull down likely conflicting changes. I like to rebase master back into the working branch. Or better yet create a test branch from it for the rebase. So it goes something like:
(master) $ git co -b work-52
do some work...
(work-52) $ git ci -a -m "awesome commit message"
(work-52) $ git co master
(master) $ git svn rebase
Huge chunk of stuff that's bound to conflict...
(master) $ git co work-52
(work-52) $ git co -b test
(test) $ git rebase master
fix conflicts and generally work out how bad things are...
(master) $ git svn rebase
just in case!
(master) $ git rebase test
(master) $ git svn dcommit
(master) $ git br -D work-52
(master) $ git br -D test
There are doubtless better ways to do these things. I'd love to hear them.
Oh and the problem I had the last couple of days:
I've never normally had a problem with this (and our repos at Atlassian had lots of branches) but this week it drove me nuts.
Make sure you've got all the goods: (master) $ git svn fetch
Check your remotes: (master) $ git br -r
Checkout the one you want: (master) $ git co remotes/cool-new-shiz
bunch of warning notes about how you're not on a local branch etc etc...
Checkout your remote into a local branch: (no branch) $ git co -b new-shiz
Note: don't use the same name for the local as the remote cause that's ambiguous and you wouldn't like git-svn when it's ambiguous.
From now on, running 'git svn rebase' in new-shiz will rebase from the cool-new-shiz branch and dcommits with commit to that SVN branch
After one dcommit to the correct branch, it'd revert to pointing to trunk. Major fuck up.
I finally solved it by editing my .git/config file. The 'svn-remote' was referring to 'blahblahlbah/trunk' when it should have been 'blahblahlbah/*'
I'm now late for work.
Peace.