On Sun, Jan 02, 2011 at 11:39:36PM +0000, graham wrote:
>> Hence, the course of action for you would probably be:
>> 1) Prepare the authors file.
>> 2) git-svn clone the Subversion repo.
>> 3) Fork its master branch to your two local branches.
> Is there a best way to do the fork? For longstanding branches I guess a
> cp -r would be better than a git branch?
I don't think so -- Git's switching of branches is light-fast and you only
should consider something like `cp -r` (but *not* exactly this, see below)
only if you for some reason really want to have these two branches
available in parallel as two checkouts (two directories on your hard
drive available both at the same time).
Note that it's possible to switch to another branch while in the middle
of hacking thanks to the `git stash` command -- you `git stash` the
changes in your work tree (and hence make it clean), switch to another
branch, do something on it, switch back, and `git stash pop` the changes
you stashed at the first step.
I think if you really want to have any two branches to be checked out in
parallel, it suggests you'd better have two different repositories for
Also there's no need to use `cp -r` in any case -- if you clone a
repository locally, Git tries to hardlink everything it clones. There
are even methods to explicitly share certain objects.
>> 4) Add another two remotes (the first one will be "svn", created by git-svn)
>> which you will use to do pushes to your staging and production
> I don't follow this step - why does one of the remotes need to be svn,
> not pure git?
Bad phrasing on my part: "the first" is meant to designate the remote
that `git svn init/clone` will create for you -- it is named "svn" by
default. Then you add two other remotes for your Git servers.
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To post to this group, send email to git-us...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at