Alrighty, again for all others looking for a solution. This is mostly from
hope I didn't break anything by replacing our internal repo names with
On the server, create a bare repo where other devs will clone from:
git init --bare Utils.git
Set a pointer to HEAD ref. This one doesn't exist yet; the push below makes
git symbolic-ref HEAD refs/heads/trunk
Allow git-daemon to serve this repository
Then, still on the server, create a fetching-repo that pushes to the bare
one (this could run in a cronjob, as post-commit-hook directly from the
subversion repository, as a Jenkins job, or whatever):
Do the actual clone. The parameters must be the same later for each
developer with git svn init.
git svn clone svn://linux01/tci/Utils -s -A author-mapping.txt Utils
Add the bare repo as remote
git remote add origin /var/git/mirror/Utils.git
We probably wont ever fetch from there; but we want to push everything
git config --unset remote.origin.fetch
git config remote.origin.push 'refs/remotes/*:refs/heads/*'
git push origin
Every developers does the following steps to get his clone:
git clone -o svn git://debian-esxi/mirror/Utils.git utils-test
git svn init -s --prefix=svn/ http://linux01/svn/tci/Utils
git svn rebase
The upstream remote name (-o svn for git clone) and the prefix for git-svn
branches (--prefix=svn/ for git svn init) must be the same for the magic to
work. In the end, both point to the same file storing the hash of the
latest commit. If those two do not point to the same file, git-svn will
update one file and git pull will update the other. And since this is a
clone from a git-svn clone, we need the first one to match (which is done
with git update-ref in the original series by Thomas).
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/groups/opt_out.