git clone 无声地失败

Question

更准确地说，我相信“git clone”成功了，但立即删除了我生成的本地存储库中的所有文件。类似的问题可以找here ，但我想不出一种方法来表达我对这个问题的看法作为答案，所以我来了。

以下是我的场景细节的概要:

我在 github 上有一个仓库。我能够克隆这个存储库，就像任何人期望在 Ubuntu 12.04 上使用 git 一样。当我尝试克隆 wiki 时出现问题(github 使它可以通过 https://github.com/<owner>/<repository>.wiki.git 访问)。我生成的本地副本是空的。运行“git status”后，我注意到 repo 的内容在克隆后立即被某个实体删除。

在分支 master 上

要提交的更改:

(使用“git reset HEAD ...”取消暂存)

已删除:<文件名>

...对于我 wiki 中的所有其他页面，依此类推。

“git branch -a”对我和另一个人返回的是同样的东西:

*主人

remotes/origin/HEAD -> origin/master

远程/来源/主人

更新 1

的确，我没有意识到暂存区和工作目录之间的区别，但似乎这不是问题所在。另一方面，它可能揭示了更多错误。

我忘了说，当我第一次克隆存储库时，我收到消息“cannot stat : filename too long”

当我运行“git reset”时，所有删除都列在“重置后未暂存的更改:”下。奇怪的是 ，它被列为 merge 而不是删除。重置后，我克隆到的目录中仍然看不到任何文件。

更新 2

我可以使用克隆文件夹中的 gitk 查看所有应该存在的 wiki 条目，但我很确定这些文件在我的文件系统的任何地方都没有以原始格式存在，否则“find/-name 2>/dev/null"应该返回一些有用的输出。

更新 3

显然我的一个文件名太长，git 无法管理。克隆后再次检查 repo，它得到了除那个文件之外的所有文件: error: unable to create file <filename>.md (File name too long)

Answer 1

请注意，除了静默失败之外，您的空文件夹，如果在克隆之前创建(并且不是由克隆创建)也将被删除。

在您的情况下，失败是因为文件名太长。
但是，更一般地说，“git clone $there $here”是允许的，即使这里目录存在，只要它是一个空目录，但命令不正确 在操作失败时将其删除。
该部分已通过 Git 2.16.x/2.17(2018 年第一季度)修复

参见 commit d45420c , commit f9e377a , commit 8486b84 , commit a4c4efd (2018 年 1 月 2 日)作者:Jeff King (peff) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit addd37c ，2018 年 1 月 23 日)}

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 )} 用于踩踏现有目录 $elsewhere 的内容，当 $elsewhere 不是 Git 2.29(2020 年第 4 季度)的空目录。

参见 commit dfaa209 (2020 年 7 月 10 日)作者:Ben Wijen (bwijen) .
^{(由 Junio C Hamano -- gitster -- merge 于 commit f175e9b ，2020 年 7 月 30 日)}

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.