3

より正確には、「git clone」は成功すると思いますが、結果のローカルリポジトリ内のすべてのファイルをすぐに削除します。同様の質問がここにありますが、質問に対する私のひねりを答えとして表現する方法を考えることができなかったので、ここにいます。

これが私のシナリオの詳細の要約です：

githubにリポジトリがあります。Ubuntu 12.04でgitを使用すると誰もが予想するように、このリポジトリのクローンを作成できます。wikiのクローンを作成しようとすると、問題が発生します（githubを使用すると、https：//github.com/ <owner> / <repository> .wiki.gitからアクセスできるようになります）。結果のローカルコピーは空です。「gitstatus」を実行すると、クローン作成直後にリポジトリの内容が一部のエンティティによって削除されていることに気付きました。

ブランチマスターについて

コミットする変更：

（「gitreset HEAD ...」を使用してステージングを解除します）

削除：<ファイル名>

...私のウィキの残りのすべてのページについても同様です。

「gitbranch-a」は、他の人と同じものを返します。

*主人

リモート/オリジン/ヘッド->オリジン/マスター

リモート/オリジン/マスター

アップデート1

確かに、ステージング領域と作業ディレクトリの違いに気づいていませんでしたが、問題ではなかったようです。一方で、それは何が悪いのかをもう少し明らかにしたかもしれません。

リポジトリのクローンを最初に作成したときに、「<long_filename>を統計できません：ファイル名が長すぎます」というメッセージが表示されることを忘れました。

「gitreset」を実行すると、すべての削除が「リセット後のステージングされていない変更」の下に表示されます。奇妙なのは<long_filename>で、これは削除ではなくマージとしてリストされています。それでも、リセット後にクローンを作成したディレクトリにファイルは表示されません。

アップデート2

クローンフォルダーからgitkを使用して、存在するはずのすべてのwikiエントリを表示できますが、ファイルがファイルシステムのどこにもraw形式で存在しないことは間違いありません。そうでない場合は、「find / -name <filename> 2> / dev / null "は、いくつかの有用な出力を返すはずです。

アップデート3

どうやら私のファイル名の1つが長すぎてgitが管理できません。クローンを作成した後にリポジトリを再度チェックアウトすると、それ以外のすべてのファイルが取得されました。 error: unable to create file <filename>.md (File name too long)

4

4 に答える 4

1

サイレントに失敗することに加えて、クローンの前に作成された（クローンによって作成されていない）空のフォルダーも削除されることに注意してください。

あなたの場合、失敗はファイル名が長すぎることが原因でした。
ただし、より一般的には、git clone $there $herここにディレクトリが存在する場合でも、空のディレクトリである限り「e」は許可されますが、操作が失敗すると、コマンドによって誤って削除されます。
その部分はGit2.16.x/ 2.17（2018年第1四半期）で修正されました

ジェフキング（）によるcommit d45420c、commit f9e377a、commit 8486b84、commit a4c4efd（2018年1月2日）を参照してください。（Junio CHamanoによってマージされました---commitaddd37c、2018年1月23日）peff
gitster

clone：作成しなかったディレクトリをクリーンアップしないでください

昔々、git-cloneそれ自体が作成しなかったディレクトリへの書き込みを拒否していました。したがって、失敗したクローンのクリーンアップルーチンは、gitおよびworktreedirsを完全に削除するだけで済みます。

55892d2 （既存の空のディレクトリへのクローン作成を許可する、2009-01-11、Git v1.6.2-rc0）では、既存のディレクトリへの書き込みを学習しました。つまり、次のことを行います。

mkdir foo
git clone will-fail foo

を削除してしまいfooます。
定義上空でなければならないので、これは大きな大惨事ではfooありません。
しかし、それはやや紛らわしいです。見つけたファイルシステムをそのままにしておく必要があります。

" git clone --separate-git-dir=$elsewhere" （man）は、既存のディレクトリの内容を踏みにじるのに使用されていました。これは、Git 2.29（2020年第4四半期）で空のディレクトリでない$elsewhere場合に失敗するように教えられています。$elsewhere

Ben Wijen（）によるcommit dfaa209（2020年7月10日）を参照してください。（濱野純雄による合併---コミットf175e9b、2020年7月30日）bwijen
gitster

git clone：空でないディレクトリにクローンを作成しないでください

サインオフ：Ben Wijen

（man）を使用し、すでに存在している場合、そのコンテンツは破棄されます。git clone--separate-git-dir realgitdirrealgitdir

したがって、既存の空でないディレクトリにクローンを作成しないようにしてください。

d45420c1 （ " ：作成cloneしなかったディレクトリをクリーンアップしない"、2018-01-02、Git v2.17.0-rc0 --バッチ＃1にリストされているマージ）が、へのクローン作成に失敗した後、クリーンアップ手順を強化した場合空のディレクトリ。指定された既存のディレクトリは空のディレクトリであると想定されているため、そのディレクトリ内のすべてを削除するように設計されたクリーンアップ手順を実行している間、そのディレクトリを保持しても問題ありません（とにかく存在しないため）。既存のリポジトリにクローンを作成する場合でも、が空で あることを確認してください。
$GIT_DIR

于 2018-01-28T21:11:53.497 に答える
0

ステージング領域と作業ディレクトリの違いに慣れていない可能性があります。

すべてのファイルが削除済みとして表示される場合、それは単にステージング領域と作業ディレクトリの間に違いがあることを意味します。具体的には; ファイルはステージング領域にありますが、作業ディレクトリにはありません。

ただやってくださいgit reset。

于 2012-10-27T00:56:28.417 に答える
0

git checkout .最後のコミット以降のすべてのローカル変更を破棄して、クリーンな状態に戻す必要があります。

于 2012-10-29T18:38:43.220 に答える
0

OSX Mountain Lionで、エラーが発生しました

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

どうやら、OSXのファインダーを作成したイライラする.DS_Storeファイルは、クローンを作成しようとしていたリモートリポジトリにありました。これは、メインコンピューターの.gitignoreファイルを更新する前に最初にプロジェクトをプッシュしたためです。

セカンダリコンピューターにgitクローンを作成する前に、リモートリポジトリから.DS_Storeを削除すると、これが修正されました。これは私が私のプライマリコンピュータからそれをした方法です：

$   git rm .DS_Store 
$   git commit -m "removed .DS_Store"
$   git push
于 2013-03-28T13:17:36.293 に答える