clone: do not clean up directories we didn't create
authorJeff King <peff@peff.net>
Tue, 2 Jan 2018 21:11:39 +0000 (16:11 -0500)
committerJunio C Hamano <gitster@pobox.com>
Wed, 3 Jan 2018 21:33:49 +0000 (13:33 -0800)
commitd45420c1c8612f085f1901c33ff6f0ccfbb72d3b
tree1f873255e9fc36973db93bd3532d5ec0deb4e987
parentf9e377adc0b1ed06e35d2c77a6c9f2687c5b950b
clone: do not clean up directories we didn't create

Once upon a time, git-clone would refuse to write into a
directory that it did not itself create. The cleanup
routines for a failed clone could therefore just remove the
git and worktree dirs completely.

In 55892d2398 (Allow cloning to an existing empty directory,
2009-01-11), we learned to write into an existing directory.
Which means that doing:

  mkdir foo
  git clone will-fail foo

ends up deleting foo. This isn't a huge catastrophe, since
by definition foo must be empty. But it's somewhat
confusing; we should leave the filesystem as we found it.

Because we know that the only directory we'll write into is
an empty one, we can handle this case by just passing the
KEEP_TOPLEVEL flag to our recursive delete (if we could
write into populated directories, we'd have to keep track of
what we wrote and what we did not, which would be much
harder).

Note that we need to handle the work-tree and git-dir
separately, though, as only one might exist (and the new
tests in t5600 cover all cases).

Reported-by: Stephan Janssen <sjanssen@you-get.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/clone.c
t/t5600-clone-fail-cleanup.sh