Re: [PATCH] Teach git-svn how to catch up with its tracking branches
- From
Asheesh Laroia <asheesh@asheesh.org>
- Date
- May 8, 2008, 06:48 UTC
- Message-ID
- <alpine.DEB.1.00.0805072332300.6948@swallowtail>
- In-Reply-To
- <20080508013956.GA24956@midwinter.com>
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.