Fixed another "source and destination both remote" error case. (Windows)

[AndrewJDR]

So I originally addressed an issue like this in PR #36 with rsyncd shares, but it also seems to crop up with plain old rsync+ssh paths.

I'll let the updated code comment do most of the talking, but basically rsync thinks there are two remotes being specified if both the source path contains a colon (e.g. c:/some/path) and the remote also contains a colon (example.org:/some/path). This code translates local "c:/" style paths to "/c" style paths to get around this. The result being an error message from rsync and a failed git fat push.

This seems like a common case so I'm surprised it hasn't been happening to others. That said, maybe there aren't many windows git-fat users out there...

[abraithwaite]

If I were to guess, you're probably the only one using this feature.

Is there any possibility that it might break something elsewhere for other people using windows?

[AndrewJDR]

If you mean rsyncd remotes, I agree I'm probably the only one using that, but ssh+rsync remotes?

I assume a ssh+rsync remote is typical use case (how else do you "git fat push"?), and it was still exhibiting the issue for me, so that's what I was referring to when I said "I'm surprised it hasn't been happening to others". :)

I think that possibility exists of outside breakage, yes. I haven't done extensive testing. It would definitely be good to discover why others aren't already having this problem on windows.

[abraithwaite]

It's probably not handled well in the code itself, irrespective of your patch. We're not escaping colons in the path but they don't appear terribly frequently on unix systems.

I'm not sure what the appropriate way to escape them would be for rsync. I'm guessing different implementations have different ways of escaping it, but I'll look into it.

[cztomczak]

ssh and rsync were tested on Windows by me and worked fine. I don't remember what was the remote url.