25

プロジェクトを Linux から Bitbucket にプッシュし、それを Windows に複製しました。Windows ではテキストファイルとして表示される 2 つのシンボリック リンクがあったことが判明しました。それらがどこを指すべきかを知っていたので、それらを宛先ファイルのコピーに置き換え、コミットしてプッシュしました。

Web インターフェースから見ると、Bitbucket リポジトリは問題ないように見えます。ただし、私の Unix マシンで git clone を実行すると、次のような 2 つのメッセージが表示されます。

error: unable to create symlink ... (File name too long)

また、以前はシンボリック リンクであった 2 つのファイルがありません。/tmp/... にクローンを作成して短いファイル名を取得しようとしましたが、同じ結果が得られました。これは、Bitbucket リポジトリで何か問題が発生したことを示唆しています。core.symlinksオンオフ試着しました。

私はシンボリックリンクなしで生活できますが、作業用のリポジトリが必要です。誰も方法を知っていますか (リポジトリを再作成する以外に)?

4

6 に答える 6

29

これは、戻ってコミットを修正する必要のない解決策です。結局のところ、レポがリモートまたは共有されている場合は実行できない可能性があります。core.symlinks=false を使用します。あなたはこれを試したと言いましたが、いつとは言いませんでした。チェックアウトの前に行う必要があります。これは、通常のクローンがデフォルトで行います。したがって、 --no-checkout オプションを使用してクローンを作成する必要があります。

git clone --no-checkout the-repo tmp-clone-dir
cd tmp-clone-dir
git config core.symlinks false
git checkout
cp the-problem-file the-problem-file.bak # make a backup
git rm the-problem-file
git commit -m 'Removed problem file pretending to be a symlink' the-problem-file
mv the-problem-file.bak the-problem-file # restore the backup; now it will be of type file
git commit -m 'Added back the problem file - now with the correct type' the-problem-file
git push origin master
cd ..
\rm -rf tmp-clone-dir  # IMPORTANT

core.symlinks=false を使用してリポジトリでこれ以上作業を行いたくないため、この最後の手順は重要です。トラブルを求めているだけです。

上記は、ファイルをシンボリックリンクではなくファイルにすることを前提としています。シンボリックリンクを意図していた場合は、最初のコミット後に停止し、tmp-clone-dir を削除し、通常のリポジトリチェックアウトに戻ってシンボリックリンクを作成してコミットします。

この方法の利点は、履歴が保持されるため、関連するクローンやブランチが壊れないことです。これの欠点は、壊れたコミットがまだそこにあり、その特定の悪いコミットを使用しようとすると問題が発生することです。

于 2014-10-25T02:01:19.153 に答える
15

モードをシンボリックリンクから通常のファイルに変更せずに偽のシンボリックリンクファイルの内容を変更し、結果をコミットするとすぐに、実際のシンボリックリンクを使用して OS で抽出できない blob を作成しました。シンボリックリンクであるはずのオブジェクトですが、その内容が長すぎてパス名にはなりません。Web インターフェースは、この問題を隠してあなたに何の恩恵も与えていません。

おそらく、そのコミットまでバックアップして修正し、その後すべてを再コミットする必要があります。git rebase -i助けになりますが、特に、この偽のシンボリックリンクであるが実際にはシンボリックリンクではない状態にある間にファイルにさらに変更を加えた場合は、簡単ではないかもしれません.

悪いコミットがabcdef123であるとすると、これを行う必要があります。

git rebase -i 'abcdef123^'

これにより、コミットのリストを含むエディターが表示されます。abcdef123最初の行にある必要があります。その行で、に変更pickしeditます。悪いコミットが複数ある場合は、それらをすべて に変更しeditます。エディターを保存して終了します。

これで、不良ファイルをコミットした時点に戻ります。これは歴史を変えるチャンスであり、かつて間違っていたことを正すことができます。でコミットを調べます

git show

元のシンボリックリンクのパス名をファイルに復元してgit adding することで、悪い部分を元に戻します。または、シンボリックリンクを適切に削除してgit rmから、新しいファイルを作成することもできますgit add。最初のオプションを選択する場合、シンボリック リンクの内容は単なるパス名であることに注意してください。これはテキスト ファイルではありません。末尾に改行がありません。改行を追加するテキスト エディターで編集すると、シンボリック リンクが壊れます (名前に改行が含まれるファイルを指します)。

を完了したらgit add、修正したコミットを履歴のその場所に再挿入します。

git commit --amend
git rebase --continue

複数のコミットを からpickに変更したedit場合は、それぞれに対してその手順を繰り返す必要があります。決勝git rebase --continueはあなたを現在に戻します。

リベース中に過去のコミットを行っていて、コミット全体が悪いことに気付いた場合 (シンボリックリンクを、それが指しているファイルの変更されていないコンテンツに置き換える以外に何もしていません)、git rebase --skip修正して続行する代わりにできます。これが発生することが事前にわかっている場合は、git rebase -iに変更する代わりに、リストpickから悪いコミットを削除することができますedit。

不正なコミットの影響を受けるブランチが複数ある場合は、ブランチごとに手順全体を繰り返す必要があります。ブランチをチェックアウトし、git rebase -i完了まで実行して ( git rebase --continue「リベースに成功しました」と表示されます)、次のブランチをチェックアウトしてもう一度実行します。

将来、開発作業を Windows と実際の OS の間で分割する場合は、Windows で cygwin を使用してください。cygwin の内部では、シンボリック リンクはシンボリック リンクであり、あなたがしたようにそれらを台無しにすることはできません。

于 2013-08-24T14:48:38.117 に答える
0

bitbucket を使用している場合は、もっと簡単な方法もあります。現在、bitbucket はファイルのオンライン削除をサポートしているため、bitbucket のリポジトリに移動して、問題のあるファイルを見つけ、[編集] ボタンと [削除] ボタンの近くにあるドロップダウン ボタンを押します。

これにより、シンボリックリンクが壊れたファイルが削除され、作業ディレクトリが再び作成されます。この可能性がある場合は、手動でリベースして削除するよりもはるかに高速です。

于 2015-07-23T08:53:15.443 に答える
0

git config --global core.longpaths true これを入れて再試行してください。それが動作します。

于 2022-01-06T09:49:10.363 に答える