There are a few more things that you might want to know when you’re using git svn.
In any version control system, you need to be able to specify files that you want the system to ignore, such as backup files, compiled executables, and so on.
In Subversion, this is done by setting the
svn:ignore property on a directory. In Git, you
create a file called .gitignore, as explained in
The .gitignore File.
Conveniently, git svn provides an easy way to
map from svn:ignore to
.gitignore. There are two approaches to
consider:
git svn create-ignore automatically creates .gitignore files to match the
svn:ignoreproperties. You can then commit them, if you’d like.git svn show-ignore finds all the
svn:ignoreproperties in your whole project and prints the entire list. You can capture the command’s output and put it in your .git/info/exclude file.
Which technique you choose depends on how covert your git svn usage is. If you don’t want to commit the .gitignore files into your repository—thus making them show up for your Subversion-using coworkers—use the exclude file. Otherwise, .gitignore is usually the way to go, because it’s automatically shared by everyone else using Git on that project.
The git svn command stores extra
housekeeping information in the .git/svn
directory. This information is used, for example, to quickly detect
whether a particular Subversion revision has already been downloaded
and so doesn’t need to be downloaded again. It also contains all the
same git-svn-id information that shows up in
imported commit messages.
If that’s the case, why do the git-svn-id
lines exist at all? The reason is that, since the lines are added to
the commit object and the content of a commit object determines its
ID, it follows that the commit ID changes after sending it through
git svn dcommit—and changing the commit IDs can
make future Git merging painful unless you follow the careful steps
listed earlier. But if Git just omitted the
git-svn-id lines, the commit IDs wouldn’t have to
change, and git svn would still work fine.
Right?
Yes, except for one important detail. The
.git/svn directory isn’t cloned with your Git
repository: an important part of Git’s security design is that only
blob, tree, and commit objects are ever shared. Hence, the
git-svn-id lines need to be part of a commit
object, and anyone with a clone of your repository will get all the
information they need to reconstruct the .git/svn
directory. This has two advantages:
If you accidentally lose your gatekeeper repository or break something, or if you disappear and there’s nobody to maintain your repository, anyone with a clone of your repository can set up a new one.
If
git-svnhas a bug and corrupts its .git/svn directory, you can regenerate it whenever you want.
You can try out regenerating the cache information whenever you want by moving the .git/svn directory out of the way. Try this:
$cd svn-all.git$mv .git/svn /tmp/git-svn-backup$git svn fetch -r33005:33142
Here, git svn regenerates its cache and
fetches the requested objects. (As before, you would normally leave
off the -r option, but that could end up downloading
thousands of commits, and this is just an example.)