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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
