Git: невозможно создать символическую ссылку (слишком длинное имя файла)
я подтолкнул проект от linux к bitbucked, а затем клонировал его на windows. Оказывается, было две символические ссылки, которые появились в виде текстовых файлов в windows. Поскольку я знал, куда они должны указывать, Я заменил их копиями файлов назначения, зафиксировал и толкнул.
теперь репозиторий butbucket выглядит нормально, когда я смотрю его из своего веб-интерфейса. Однако клон git на моей машине unix дает мне два сообщения, такие как:
error: unable to create symlink ... (File name too long)
и два файла, которые ранее были символическими ссылками, отсутствуют. Я попытался клонировать в /tmp/... чтобы получить более короткие имена файлов, но получили те же результаты. Это говорит о том, что что-то пошло не так с хранилищем bitbucket. Я пытался!--1--> ВКЛ и выкл.
Я могу жить без символических ссылок, но я хотел бы иметь рабочий репозиторий. Кто-нибудь знает способ (кроме воссоздания репозитория)?
4 ответов
как только вы изменили содержимое фейк-ссылка-файл без изменения его режима от симлинк на регулярные файл и передал результат, вы сделали большой двоичный объект может быть извлечен на ОС с реальными симлинки, потому что у вас есть объект, который должен быть ссылкой, но его содержание слишком долго, чтобы быть путь. Веб-интерфейс не делает вам никаких одолжений, скрывая эту проблему.
вам, вероятно, придется вернуться к этой фиксации, исправить ее и повторно зафиксировать все после него. git rebase -i поможет, но это все равно может быть непросто, особенно если вы внесли больше изменений в файлы, пока они находились в этом фиктивном состоянии символической ссылки, но не совсем символической.
предположим, что плохая фиксация abcdef123, вам нужно сделать это:
git rebase -i 'abcdef123^'
который поместит вас в Редактор со списком коммитов. abcdef123 должно быть на первой строке. На этой линии измените pick to edit. Если есть несколько плохих фиксаций, измените все их edit. Сохраните и закройте редактор.
теперь ты вернешься в тот момент времени, когда вы совершили плохой файл. Это твой шанс изменить историю, исправить то, что когда-то пошло не так. Проверьте фиксацию с помощью
git show
и отменить плохую часть, восстановив исходный путь символической ссылки в файл и git adding это. Или вы действительно можете избавиться от символической ссылки с помощью git rm, затем создайте новый файл и git add что. Если вы выбираете во-первых, имейте в виду, что содержимое символической ссылки-это просто путь. Это не текстовый файл - у него нет новой строки на конце. Если вы редактируете его с помощью текстового редактора, который добавляет новую строку, у вас будет сломанная символическая ссылка (указывающая на файл с новой строкой в его имени).
после того как вы сделали свой git add, вставьте фиксированную фиксацию на свое место в истории:
git commit --amend
git rebase --continue
если вы изменили несколько коммитов от pick to edit вам придется повторить эту процедуру для каждого. Финал git rebase --continue вернет вас в настоящее.
если вы находитесь в прошлом фиксации во время ребазы, и вы обнаружите, что вся фиксация плохая (она ничего не сделала, кроме замены символической ссылки на немодифицированное содержимое файла, на который она указывает), то вы можете git rebase --skip вместо внесения поправок и продолжается. Если вы заранее знаете, что это произойдет, вы можете просто удалить плохую фиксацию из git rebase -i список вместо изменения своего pick в edit.
если у вас есть несколько ветвей, затронутых плохой фиксацией, вам придется повторить всю процедуру для каждой ветви. Проверьте ветку, запустите git rebase -i до завершения (когда git rebase --continue говорит "успешно перезагружен"), затем проверьте следующую ветку и сделайте это снова.
в будущем, при разделении вашей работы по разработке между Windows и реальной ОС, сделайте свою работу Windows с cygwin. Внутри cygwin символические ссылки являются символическими ссылками, и вы не можете беспорядок они такие же, как ты.
вот решение, которое не требует, чтобы вы вернулись и исправили фиксации. В конце концов, это может быть невозможно, если РЕПО является удаленным или общим. Он использует ядра.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, найти файл, который является проблемным, нажмите кнопку раскрывающегося списка рядом с кнопкой "редактировать" и "удалить".
это удалит файл с сломанной символической ссылкой, и у вас снова будет рабочий каталог. если это возможно, это намного быстрее, чем перебазирование и удаление вручную.