In git 1.7.9.5 I could run the following lines without error:
export SVNPASS=readonly
git clone [email protected]:dtenenbaum/RGalaxy.test.git
cd RGalaxy.test/
git config --add svn-remote.hedgehog.url https://hedgehog.fhcrc.org/bioconductor/trunk/madman/Rpacks/RGalaxy
git config --add svn-remote.hedgehog.fetch :refs/remotes/hedgehog
# the following is a shortcut to avoid fetching every commit since antiquity, since I happen to know the commit number
# where this folder was added to svn:
echo $SVNPASS | git svn fetch --username readonly hedgehog -r 65762:HEAD
git checkout -b local-hedgehog -t hedgehog
In git 1.8.3.4 and 1.8.4.1 that last line results in:
fatal: Cannot setup tracking information; starting point 'hedgehog' is not a branch.
The comments to this question suggest downgrading, but I'd like to know why this is happening: is it a bug? And if so, has it been reported? Or is there a better way to do this and if so, what is it?
Incidentally, "git branch -a" returns:
* master
remotes/hedgehog
remotes/origin/HEAD -> origin/master
remotes/origin/master
This is not considered as a bug by git-svn developpers. As a matter of fact, this is a result of a bug fix in v1.8.3.2. Setting up your local local-hedgehog
to track git-svn's hedgehog
will no longer work.
From now on, simply doing
git checkout -b hedgehog remotes/hedgehog
is enough to be able to do all your usual git-svn operations (git svn rebase
, git svn dcommit
, etc.).
Here is the explanation by Johan Herland:
Prior to v1.8.3.2 this still sort-of works (as you observe below), because the code fails to realize the remote is invalid, and falls back to setting branch.feat-bar.remote = "." (i.e. the current repo). This might seem like an ok practice until you realize that a "git push" back to that invalid upstream would happily overwrite refs/remotes/(mirror/)feat-bar, and thus break git-svn's internal state.
This bug was fixed in v1.8.3.2, more specifically 41c21f22 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*), and you can read more about the rationale in that commit message.
The end result for you is that setting up your local feat-bar to track git-svn's feat-bar will no longer be accepted once you upgrade to >= v1.8.3.2. The correct way to set up a local feat-bar branch to work on top of git-svn's feat-bar is instead to forgo the upstream relationship and simply do "git checkout -b feat-bar refs/remotes/(mirror/)feat-bar".
If you want more details, I suggest reading his whole post.