On Wed, 7 May 2008, Steven Grimm wrote:
In environments where a lot of people are sharing an svn repository using
git-svn, everyone has identical, but individually maintained, tracking
branches.
To further muddy the waters, let me talk about my setup, also one with a
"central git repository" from which all developers clone, and also one
based on a Subversion tree.
The way I handle it is that, hidden somewhere, I have an account with a
cron job that does this:
$ git svn fetch
$ git push origin refs/remotes/*:refs/heads/*
$ git push origin refs/remotes/trunk:refs/heads/master
The first push synchronizes "origin" to have the same branches as this
git-svn copy of the git repository, and the second updates "origin" so
that it has a "master"; without that second step, "git clone" will error
out when it get to its checkout phase.
Note that in .git/config, the [remote "origin"] section has no "fetch"
parameter. If it did have one, a would end up creating the branch
origin/master on the second push, and origin/origin/master on the third,
and so on.
After the push, "origin" ends up being a git repository that looks just
like the svn repository we're cloning. When you "git clone" it, the
remote has all the tags and branches of the upstream svn repository; and
as the upstream svn repository updates its branches, the git branches get
those updates.
I'm not saying this patch shouldn't be accepted; I have no comment on it.
I just want to see what others think of my approach to this workflow.
-- Asheesh.
--
What happened last night can happen again.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
