Git：シンボリックリンクを作成できません（ファイル名が長すぎます）
私はプロジェクトをLinuxからBitbucketにプッシュし、それをWindowsに複製しました。 Windowsではテキストファイルとして表示される2つのシンボリックリンクがあったことが判明しました。それらがどこを指すべきかを知っていたので、それらを宛先ファイルのコピーに置き換え、コミットしてプッシュしました。
これで、Bitbucketリポジトリは、Webインターフェイスから見ると問題ないように見えます。ただし、Unixマシンのgit cloneは、次のような2つのメッセージを表示します。
error: unable to create symlink ... (File name too long)
以前はシンボリックリンクであった2つのファイルはありません。/tmp/...にクローンを作成してファイル名を短くしようとしましたが、同じ結果が得られました。これは、Bitbucketリポジトリで問題が発生したことを示しています。私は試した core.symlinks オンとオフ。
シンボリックリンクがなくても生活できますが、有効なリポジトリが必要です。誰かが（リポジトリを再作成する以外に）方法を知っていますか？
モードをシンボリックリンクから通常のファイルに変更せずに偽のシンボリックリンクファイルのコンテンツを変更して結果をコミットするとすぐに、実際のシンボリックリンクがあるOSでは抽出できないblobが作成されます。シンボリックリンクであるはずのオブジェクトですが、その内容が長すぎてパス名にはなりません。 Webインターフェースは、この問題を隠すことによってあなたに何の恩恵も与えていません。
おそらく、そのコミットにバックアップして修正し、その後すべてを再コミットする必要があります。 git rebase -iは役に立ちますが、それでも簡単ではない可能性があります。特に、ファイルがこの偽のシンボリックリンク状態にある間にファイルにさらに変更を加えた場合はなおさらです。
不正なコミットがabcdef123であるとすると、次のようにする必要があります。
git rebase -i 'abcdef123^'
これにより、コミットのリストを含むエディターが表示されます。 abcdef123は最初の行にある必要があります。その行で、pickをeditに変更します。不正なコミットが複数ある場合は、それらすべてをeditに変更します。エディターを保存して終了します。
これで、不良ファイルをコミットした時点に戻ります。これは歴史を変えるチャンスであり、かつてはうまくいかなかったことを正しくします。でコミットを検査します
git show
元のシンボリックリンクパス名をファイルに復元し、それをgit addして、問題のある部分を元に戻します。または、git rmを使用してシンボリックリンクを適切に削除してから、新しいファイルを作成してgit addすることもできます。最初のオプションを選択する場合、シンボリックリンクの内容は単なるパス名であることに注意してください。これはテキストファイルではありません。末尾に改行がありません。改行を追加するテキストエディタで編集すると、シンボリックリンクが壊れます（名前に改行が含まれるファイルを指します）。
git addを実行した後、固定コミットを履歴内のその場所に再挿入します。
git commit --amend
git rebase --continue
複数のコミットをpickからeditに変更した場合は、それぞれに対してその手順を繰り返す必要があります。最後のgit rebase --continueは、現在に戻ります。
リベース中に過去のコミットを行っていて、コミット全体が不良であることがわかった場合（シンボリックリンクを、それが指すファイルの変更されていないコンテンツに置き換える以外に何もしなかった）、代わりにgit rebase --skipを実行できます。修正と継続。これが発生することが事前にわかっている場合は、pickをeditに変更する代わりに、git rebase -iリストから不正なコミットを削除できます。
不正なコミットの影響を受けるブランチが複数ある場合は、ブランチごとに手順全体を繰り返す必要があります。ブランチをチェックアウトし、git rebase -iを実行して完了し（git rebase --continueが「正常にリベースされました」と表示されたとき）、次のブランチをチェックアウトして再度実行します。
将来、開発作業をWindowsと実際のOSに分割するときは、Windowsでcygwinを使用して作業してください。 cygwinの内部では、シンボリックリンクはシンボリックリンクであり、あなたがしたようにそれらを台無しにすることはできません。
これは、戻ってコミットを修正する必要がないソリューションです。結局のところ、リポジトリがリモートまたは共有されている場合は実行できない可能性があります。 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を削除し、通常のリポジトリチェックアウトに戻ってシンボリックリンクを作成してコミットします。
この方法の利点は、履歴が保持されるため、関連するクローンやブランチを壊さないことです。これの欠点は、壊れたコミットがまだそこにあり、その特定の悪いコミットを使おうとすると誰にとっても問題を引き起こすことです。
私はこの問題を抱えていました、これは私のためにそれを解決しました：
git config core.symlinks false
git rm <problem-file>
git commit <problem-file>
git Push
git config core.symlinks true
Bitbucketを使用している場合は、より簡単な方法もあります。現在、bitbucketはファイルのオンライン削除をサポートしているので、bitbucketのリポジトリに移動し、問題のあるファイルを見つけて、[編集]ボタンと[削除]の近くにあるドロップダウンボタンを押します。
これにより、シンボリックリンクが壊れたファイルが削除され、作業ディレクトリが再び作成されます。これが可能性がある場合は、手動でリベースして削除するよりもはるかに高速です。
少数のファイルでも同じ問題が発生しました。ソース内のファイル（シンボリックリンクではなくなった）を削除しないgit remove --cached <file>を使用して、リポジトリからそれらを削除することで解決しました。すべてが削除されると、gitはそれらがまだ存在していることを確認するので、git add .を使用してそれらを追加し直してから、コミットし直すことができます。