git clone fails silently

Question

To be more precise, I believe "git clone" succeeds, but immediately deletes all the files in my resulting local repo. A similar question can be found here, but I couldn't think of a way to phrase my twist on the question as an answer, so here I am.

Here's the rundown on the specifics of my scenario:

I have a repository on github. I am able to clone this repository as anyone would expect using git on Ubuntu 12.04. The problem arises when I try to clone the wiki (github makes this accessible via https://github.com/<owner>/<repository>.wiki.git). My resulting local copy is empty. Upon running "git status" I notice that the contents of the repo were deleted by some entity immediately after cloning.

On branch master

Changes to be committed:

(use "git reset HEAD ..." to unstage)

deleted: <filename>

...And so on for all the rest of the pages in my wiki.

"git branch -a" returns the same thing for me as for the other guy:

*master

remotes/origin/HEAD -> origin/master

remotes/origin/master

update 1

It's true I was not aware of the difference between the staging area and the working directory, but it seems that was not the issue. On the other hand, it may have revealed a bit more of what is wrong.

I forgot to mention that when I first clone the repository, I get the message "cannot stat <long_filename>: filename too long"

When I run "git reset" all of the deletions are listed under "unstaged changes after reset:". The odd one out is <long_filename> which is listed as a merge instead of a deletion. Still, no files are visible in the directory I cloned to after the reset.

update 2

I can view all the wiki entries that should be present by using gitk from the cloned folder, but I am quite certain that the files are not present in a raw format anywhere on my filesystem, otherwise "find / -name <filename> 2>/dev/null" should return some useful output.

update 3

Apparently one of my filenames is too long for git to manage. Checking out the repo again after cloning it got all the files but that one: error: unable to create file <filename>.md (File name too long)

Answer 1

Note that, in addition of failing silently, your empty folder, if created before the clone (and not created by the clone) would be removed as well.

In your case, the failure was because of a filename too long.
But, more generally, "git clone $there $here" is allowed even when here directory exists as long as it is an empty directory, but the command incorrectly removed it upon a failure of the operation.
That part has been fixed with Git 2.16.x/2.17 (Q1 2018)

See commit d45420c, commit f9e377a, commit 8486b84, commit a4c4efd (02 Jan 2018) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit addd37c, 23 Jan 2018)}

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 55892d2 (Allow cloning to an existing empty directory, 2009-01-11, Git v1.6.2-rc0), 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.

---

"git clone --separate-git-dir=$elsewhere"^(man) used to stomp on the contents of the existing directory $elsewhere, which has been taught to fail when $elsewhere is not an empty directory with Git 2.29 (Q4 2020).

See commit dfaa209 (10 Jul 2020) by Ben Wijen (bwijen).
^{(Merged by Junio C Hamano -- gitster -- in commit f175e9b, 30 Jul 2020)}

git clone: don't clone into non-empty directory

^{Signed-off-by: Ben Wijen}

When using git clone^(man) with --separate-git-dir realgitdir and realgitdir already exists, it's content is destroyed.

So, make sure we don't clone into an existing non-empty directory.

When d45420c1 ("clone: do not clean up directories we didn't create", 2018-01-02, Git v2.17.0-rc0 -- merge listed in batch #1) tightened the clean-up procedure after a failed cloning into an empty directory, it assumed that the existing directory given is an empty one so it is OK to keep that directory, while running the clean-up procedure that is designed to remove everything in it (since there won't be any, anyway).
Check and make sure that the $GIT_DIR is empty even cloning into an existing repository.

Answer 2

On OSX Mountain Lion, I had the error

error: Untracked working tree file '.DS_Store' would be overwritten by merge.

Apparantly the irritating .DS_Store file created my OSX's finder was in my remote repository that I was trying to clone. This was because I had initially pushed the project before updating the .gitignore file on my main computer.

Removing the .DS_Store from the remote repository before git cloning to my secondary computer fixed this for me. This is how I did it from my primary computer:

$   git rm .DS_Store 
$   git commit -m "removed .DS_Store"
$   git push

Answer 3

git checkout . should discard all local changes since the last commit, reverting you back to a clean state.

Answer 4

You are probably not familiarized with the difference between the staging area and the working directory.

If all the files show as deleted that simply means there's a difference between your staging area and the working directory; specifically; the files are in the staging area but not on your working directory.

Just do git reset.