Learning git-svn in 5min

You are a SVN user and you don't have time to learn new things, here is a 5min course to get started with Git and git-svn.

1. Import your SVN repository in Git:
   git svn clone -s https://svn.foo.com/svn/proj
2. Make your own Git branch:
   git checkout -b work trunk
   
3. git add the files you changed.
4. git commit
5. Want to sync with the remote master SVN repos?
   git svn dcommit

There you go!  And guess what, svn-wrapper supports Git!

Some more details now:

1. The various -s argument is simply here to tell git svn that you use the standard SVN-style layout (trunk/branches/tags).
   
2. You must not work in a remote branch.  That's why the 2nd step is to setup a local branch where your work will happen. I checked-out trunk but you could also checkout branch "1.0" or whatever.
3. This is the only notable difference with SVN for basic usage.  With subversion, you svn add your files once and then SVN will track them automatically.  Git does not track files but content.  I know this might sound weird and hard to digest when you start using Git, but that's how Git is and there are many reasons why things are such.  So for now, just don't forget that you must git add the files you want to commit.  Alternatively, you can use git commit -a to commit all the files.  Be warned though that if you do this, git will schedule all the files for the next commit.  It will remove all files that disappeared in the mean time too.
4. Don't forget that the commit will be done in your local repository only.
5. git-svn will push each commit you made in the remote SVN repository.  Each commit will be pushed separately with the log message you gave to Git.
6. Someone committed in the SVN repository?  Fetch the new revisions with git svn fetch

Now you can read the previous post in order to find some useful references that are worth reading.  You will quickly see that the time you invest learning Git will pay off (for those of you who are very concerned with ROI). git-svn is ironically the best SVN client IMO.

Some questions you might ask:

Where does git store its stuff?
In the single .git folder at the root of the working copy.  Everything is there, you don't have .git folders all over the place like .svn folders.

Where are my branches and stuff?
They are in .git/refs/remotes/, you can easily switch between branches with git checkout.

What about my svn:ignore?
You can import them in git with:
(echo; git-svn show-ignore) >> .git/info/exclude

What about my svn:externals?
Sorry, they are not yet supported by git-svn.  But you're not lost!  Create another git repository with the svn:external repository and put that repository where it's meant to be and checkout the revision that was pinned in the SVN.  Look near the end of .git/svn//unhandled.log, you'll see:
rREVISION1
+dir_prop: trunk svn:externals external_name%20-r%20REVISION2%20URL
This tells you that at REVISION1 in the branch , the svn:externals pinned the revision REVISION2 of URL as external_name.
You need to find the sha1 hash of this revision in git, enter the "external" repository and do:
grep -r rREVISION2 .git
.git/logs/refs/remotes/trunk: [...] rREVISION2
There you go, you can simply issue:
git checkout

Still not convinced by Git?

• Git is way faster than SVN
• Git is distributed (you can work offline which is a great advantage for laptop users)
• Git makes branching and tagging extremely cheap and convenient.
• Most important: Git makes merging a trivial yet powerful operation.  Subversion is flawed in this respect, merging is a pain, you have to manually track the last revision that was merged, you loose the history, etc.  Git does not have all these disadvantages.  Merging is done right: fast, easy, reliable.  As a bonus, you even get less conflicts.
• Git has tons of sexy features that SVN will probably never have and SVN users can only dream about.  For instance, Git can instantly tell you where does THIS LINE come from, even if this line moved across different files over years.
• Git is safe and reliable.  We also use versioning systems because we want to keep a safe backup of all the history of a project.  But servers crash, filesystems get corrupted, we all have this kind of problem. Sometimes malicious people try to fiddle with the history on well-known public servers.  Git checks every single thing it controls with sha1 sums, there is no way you can screw things up without noticing.  This reason is actually good enough that everyone actually carrying about their code should switch to Git right now. With a single 40-bytes sha1 hash, you can make sure that, not only a single revision is OK, but that the entire history, all the files and stuff straight from the beginning until this revision are OK.
• Git makes it a lot easier for everyone to contribute.  No endless delicate political discussions about commit access, people pull changes from each other, usually from the people they trust.  Everyone maintains their own branches and publish only what they want to publish.
• Git is highly optimized.  The first thing people usually worry about is "OMG, this is gonna take a hell lot of space if I gotta import the entire history on my local hard drive".  First off, you don't have to import everything if you're wrapping SVN repositories with Git (see the links in my previous post).  Second thing, most of my Git repos are actually smaller than the same working copy in SVN (even though the Git one actually has the entire history it its .git!)  I have an example at hand, a 1340 revision SVN working copy freshly checked out.  It's 7.6MB.  The same working copy in Git but with the entire history of the 1340 revisions (for all branches and tags) is only 6.6MB.