Grzegorz Kossakowski venit, vidit, dixit 08.12.2008 19:26: > Michael J Gruber pisze: >> Could it be as simple as a missing "cd cocoon" between git clone and git >> svn rebase? No, you probably did that. > > That would be too easy. > >> But note that you did not follow Peter's instructions. The point is that >> your clone creates "remotes/origin/trunk" whereas Peter's instructions >> mirror the source, creating "remotes/trunk", which is what git svn needs >> (unless you say "git svn init -s --prefix=origin/" or "git config >> svn-remote.svn.fetch trunk:refs/trunk" etc.). The prefix solution should >> be the best. >> >> Michael >> >> P.S.: Peter starts off a different layout (standard svn remotes, which >> need special instructions to be cloned). Ordinary clone + git svn init >> --prefix=origin/ should work fine for the cocoon layout. > > This almost worked. Actually, Cocoon repository hosted on Jukka's server does not have local head > named "trunk" so there is no remotes/origin/trunk created during cloning process. > > I had to run: > > git update-ref refs/remotes/origin/trunk refs/heads/master Uhm, I misread gitweb output... So, cocoon really has remotes/trunk, so that Peter's original suggestion would work. If the cocoon git-svn clone isn't going to change then Peter's way of doing it might be the best: it ensures that future pulls from origin (cocoon) will update the correct refs so that you can pull/fetch from the git-svn clone (fast) and then git-svn rebase rather than git-svn rebasing directly, which would fetch new commits from the svn repo first (slow). I think all in all it shows that git-svns default location for branches is not the best choice: they're not local, but they're no "proper" remotes either (unless you use --prefix). Michael -- 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
