summaryrefslogtreecommitdiff
path: root/contrib
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2018-01-02 16:11:39 -0500
committerLibravatar Junio C Hamano <gitster@pobox.com>2018-01-03 13:33:49 -0800
commitd45420c1c8612f085f1901c33ff6f0ccfbb72d3b (patch)
tree1f873255e9fc36973db93bd3532d5ec0deb4e987 /contrib
parentclone: factor out dir_exists() helper (diff)
downloadtgif-d45420c1c8612f085f1901c33ff6f0ccfbb72d3b.tar.xz
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>
Diffstat (limited to 'contrib')
0 files changed, 0 insertions, 0 deletions