Re: git-svn bug report: %20 in http:// should translate to a space ' ' automatically
- From
Björn Steinbrink <b.steinbrink@gmx.de>
- Date
- Aug 15, 2009, 18:16 UTC
- Message-ID
- <20090815181637.GC19833@atjola.homenet>
- In-Reply-To
- <4A86F4DA.5090605@smullindesign.com>
On 2009.08.15 11:48:10 -0600, Mike Smullin wrote:
> Hello, > > This one took me over an hour to figure out with the help of doener > in #git on irc.freenode.net:
[IRC log omitted]
To wrap that up:
1) git svn clone http://host/repo/path%20with%20spaces/foo/bar/goo
Works, but see below.
2) git svn clone -Tgoo http://host/repo/path%20with%20spaces/foo/bar
Fails.
3) git svn clone -Tgoo "http://host/repo/path with spaces/foo/bar"
Works.
In Mike's case, there was a rename from foo/goo to foo/bar/goo. 1) fails to follow that rename, 2) just completely fails and 3) works and follows the rename.
Cloning via http:// didn't provide any interesting error messages, but cloning via svn+ssh:// showed:
For 1) W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: File not found: revision 100, path '/path with spaces/foo/bar"
For 2) W: Ignoring error from SVN, path probably does not exist: (160013): Filesystem has no item: File not found: revision 100, path '/path%20with%20spaces/foo/bar"
So 2) somehow has the spaces escaped there, but 1) doesn't.
I guess that 1) has it right, and the rename detection just doesn't work because the old name is outside of "url" for the svn-remote. And 2) somehow gets it wrong, likely double-escaping the spaces or so. (I have no idea...)
My totally uneducated guess is that git-svn fails to unescaped the path when it splits it into the higher-level part for "url" and the rest of it for "fetch".
HTH Björn