On Tue, Jan 02, 2018 at 06:12:35AM -0500, Robert P. J. Day wrote: > > I just noticed the following behaviour on macOS 10.13.2 running Git v2.15.0: > > > > 1. `mkdir new-folder` > > 2. `ls` - shows new-folder > > 3. `git clone [repo] new-folder` > > 4. Git asks for password > > 5. I cancel by pressing ctrl+c > > > > Result: > > `ls` no longer shows new-folder. > > > > Expected result: > > `ls` shows new-folder > > > > I’m not sure whether this might be a case of ‘works as intended’, > > but it’s not what I’d expect. > > i'm *pretty* sure that the optional directory name you supply is > meant to represent a directory you want git to *create* for you, not > one that already exists. that means the behaviour you see makes sense > -- if git assumes it was supposed to create the directory, and you > cancel the clone, it reasonably assumes it should get rid of it. Correct. In the early days we required that the "new-folder" directory not exist, and the initial "git clone" would have bailed in that case. Any directory we removed would have been one we created. That changed in 55892d2398 (Allow cloning to an existing empty directory, 2009-01-11), and we continue to allow only empty directories. So I don't think there's an urgent data-loss bug here; we will only ever destroy an empty directory. However, the original intent was to leave the filesystem as we found it on a failed or aborted clone, and we obviously don't do that in this case. So it might be nice if we could restore it to an empty directory. Restoring the original contents in the general case is hard, since other parts of the clone may have created arbitrary files. But if we know the original is just empty, we can simply delete everything in it, but not the outer directory. -Peff
