On 20.09.2013 09:29, Nick Sabalausky wrote:
fatal: Could not read from remote repository.
>
>Please make sure you have the correct access rights
>and the repository exists.
>Deletion of directory '.' failed. Should I try again? (y/n) n
>Entering dir: C:\Users\Rainer\AppData\Local\Temp\.create_dmd_release
>Couldn't do git protocol, falling back to 'https://'...
>Removing dir: dmd
>Creating dir: dmd
>Entering dir: dmd
>Cloning:https://github.com/D-Programming-Language/dmd.git
>...
Ok, I see what's happening. It's git that's doing that:
This create_dmd_release tool*tries* to clone using git/ssh protocol
because it's supposed to be faster, albeit less compatible. But if that
fails (as it does for both you and me...some rights/certificate issue
apparently), then the script tries again using the slower, but more
reliable HTTPS protocol.
But here's the thing: When git tries to clone, and the clone fails,
then git's nice about it and tries to clean up the mess it left behind
by deleting the directory with the failed clone. Unfortunately, Windows
likes to randomly hold file locks open (or maybe it's a bug in your
version of git that's holding an old file handle open). So git's unable
to delete the failed-clone directory and asks if you want to try again.
I can't find a cmdline switch to tell "git clone" to always retry
(or to never retry), so I don't think there's much create_dmd_release
can do about it, short of reading git's output, scanning for that
question, and sending a 'y'. But that seems like overkill. It may be
better to just let people answer on their own if they get that.
I noticed that it is the git process that has a handle on that
directory. It seems to able to delete the directory if you run git from
the parent directory and pass "dmd" instead of ".".
