When checking out an SVN repository which gives a HTTP 301 (Moved Permanently), svn doesn't
follow the redirect but rather requires the user to do so manually and quite with exit code 1:

# checkout with SVN
$ LANG=C svn co http://remotefoo localfoo
svn: Repository moved permanently to 'https://remotefoo'; please relocate

As inconvenient as this might be, changing http to https then does the trick.
Now, when checking out the same repository using git-svn, an empty repository is created,
but then git-svn recognises the same issue and quits without cleaning up the unusable git repo:

# checkout with git-svn
$ LANG=C git svn clone http://remotefoo/ localfoo
Initialized empty Git repository in /tmp/localfoo/.git/
Repository has been moved: Repository moved permanently to 'https://remotefoo/'; please relocate at /usr/lib/git-core/git-svn line 1494

# checkout with git-svn using HTTPS then
$ LANG=C git svn clone https://remotefoo/ localfoo
svn-remote.svn.url already set: http://remotefoo
wanted to set to: https://remotefoo

# ok didn't work, maybe we can make something out of the broken local repository?
# git svn switch doesn't seem to exist after all...
$ cd localfoo; git svn rebase
fatal: ambiguous argument 'HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions
log --no-color --first-parent --pretty=medium HEAD: command returned error: 128

# try initialising by hand
$ git svn init https://remotefoo
svn-remote.svn.url already set: http://remotefoo
wanted to set to: https://remotefoo
# it doesn't want to touch the git-svn "url" in .git/config, same like above

# just for fun, try initialising with wrong HTTP url again
$ git svn init http://remotefoo
Remote ref refs/remote/git-svn is tracked by
  "svn-remote.svn.fetch=:refs/remotes/git-svn"
and
  "svn-remote.svn.fetch=:refs/remotes/git-svn"
Please resolve this ambiguity in your git configuration file before continuing
# ok, so this time it adds a second git-svn "fetch" to .git/config which doesn't make any sense whatsoever

There are two ways out of this: Removing the localfoo directory and starting again
with HTTPS, or manually changing the git-svn "url" in .git/config and calling
git svn fetch. The latter should be done automatically by git-svn in this case
for the convenience of the user, ideally even automatically when recognising
the 301 message from svn, but otherwise at least when re-cloning with the
updated HTTPS URL.

tags 524306 + upstream
retitle 524306 git svn: follow redirects
severity 524306 wishlist

Hi Josef,

Josef Spillner wrote:
[...]
[...]

I see a few bugs here:

1. Sometimes I want to just throw all the git svn metadata away and
   start over.  I can: just delete the .git/svn directory, edit
   .git/config, and I’m done.  Since the git-svn(1) man page does not
   explain it, how is anyone supposed to know that?

2. The error message when there is stale metadata around is bordering
   on useless.

3. The little amount of stale metadata from a ‘git svn clone’ failing
   very early is not useful.  git svn should just delete it.

4. An incomplete ‘git svn clone’ leaves the repository in an “ugly”
   state.  Probably if there are no revisions fetched, it should be
   as though the user did not give any command at all; if there are
   only a few revisions fetched, it should be as though the user
   ran ‘git svn clone’ earlier in the project’s history; and so on.

   Unfortunately, there is some up-front work that is done before a
   single revision gets fetched, so this one requires a little more
   thinking.

5. git svn does not follow redirects.

#5 is easy to characterize and I think a motivated person should not
find it hard to fix.  So I’m going to pretend you asked for that. ;-)

Work on any of the others would be welcome, too.

Regards,
Jonathan