git clone doesn't cleanup on failure when getcwd fails

 
If you’re in a shell in a directory which no longer exists (because, say, another terminal removed it), then getcwd() will fail, at least on OS X Yosemite 10.10.2. In this case, git clone will fail. That’s totally reasonable.  

If you invoke git clone with the git clone <repo> <dir> syntax, then <dir> will be created, but it will be empty.

This was unexpected - I would think the failure case shouldn’t leave this empty directory, but should instead clean up after itself.

I’m not alone: golang’s go get command for installing third-party packages performs a `git clone <repo> <dir>` only if <dir> does not already exist - if it does exist, then go believes that the package is already installed, and so does nothing. So, if you call go get from within a directory which no longer exists, git will create the empty directory, putting go get into a bad state.

Concrete example:

Make a dummy repo in /tmp/somerepo: tty1: $ cd /tmp $ git init somerepo

In another tty, make a /tmp/poof and enter it tty2: $ mkdir /tmp/poof $ cd /tmp/poof

In the first tty, delete /tmp/poof tty1: $ rmdir /tmp/poof

Finally, in the second tty, clone: tty2: $ git clone /tmp/somerepo /tmp/newcopy fatal: Could not get current working directory: No such file or directory $ ls /tmp/newcopy && echo "yes, it exists" yes, it exists

My version details:

$ git version git version 2.3.2

$ uname -a Darwin mbp.local 14.1.0 Darwin Kernel Version 14.1.0: Thu Feb 26 19:26:47 PST 2015; root:xnu-2782.10.73~1/RELEASE_X86_64 x86_64