Используя git 1.6.4.2, когда я попытался, git pull
я получаю эту ошибку:
error: unable to resolve reference refs/remotes/origin/LT558-optimize-sql: No such file or directory
From git+ssh://remoteserver/~/misk5
! [new branch] LT558-optimize-sql -> origin/LT558-optimize-sql (unable to update local ref)
error: unable to resolve reference refs/remotes/origin/split-css: No such file or directory
! [new branch] split-css -> origin/split-css (unable to update local ref)
Я пытался git remote prune origin
, но это не помогло.
Ответы:
Попробуйте очистить ваш локальный репозиторий с помощью:
man git-gc (1):
man git-remote (1):
источник
git remote prune origin
команда выполняться на моей локальной рабочей копии или в удаленном хранилище?Случилось и со мной. В моем случае плохой рефери был мастером, и я сделал следующее:
Это заставило git восстановить файл ref. После этого все снова заработало как положено.
источник
.git
является ли папка, выполнив,ls -la
если нет, просмотрите содержимое файла.git
файла, чтобы найти фактическую папку .git, в которой находятся ссылки..git
содержимое файла в моем случае:gitdir: ../.git/modules/my-submodule-name
Это сделало работу для меня:
источник
git remote prune origin
Для меня это работало, чтобы удалить файлы, которые выбрасывают ошибки из папки
.git/refs/remotes/origin/
.источник
NULL
s.Попробуй это:
источник
Выполните следующие команды:
источник
Я просто хотел бы добавить, как это может случиться, что ссылка не работает.
Возможная первопричина
В моей системе (Windows 7 64-бит), когда BSOD происходит , некоторые из сохраненных справочных файлов (скорее всего , в настоящее время открыты / писалась в BSOD , когда произошло) заменяются
NULL
символами (ASCII 0).Как уже упоминалось, чтобы исправить это, достаточно просто удалить эти недопустимые эталонные файлы и повторно извлечь или повторно извлечь репозиторий.
пример
Ошибка:
cannot lock ref 'refs/remotes/origin/some/branch': unable to resolve reference 'refs/remotes/origin/some/branch': reference broken
Решение: удалите файл
%repo_root%/.git/refs/remotes/origin/some/branch
источник
error: cannot lock ref 'refs/remotes/origin/master': unable to resolve reference 'refs/remotes/origin/master': reference broken
, Попыткаgit pull
после удаления первого файла вернуласьfatal: update_ref failed for ref 'HEAD': cannot lock ref 'HEAD': unable to resolve reference 'refs/heads/master': reference broken
. После удаления второй файлgit pull origin master
прошел успешно.У меня возникла та же проблема, и я решил ее, перейдя в файл, в котором он ошибался:
Этот файл был полон нулей, я заменил его последней версией из github.
источник
.git/refs/remotes/origin/master
был просто пуст. Решил проблему, удалив ее.В моем случае проблема была решена после того, как я удалил все справочные файлы удаления в каталоге
.git
.Если вы посмотрите на сообщение, оно сообщит вам, какие файлы вам нужно удалить (в частности).
Файлы для удаления находятся под
.git/refs/remotes
.Я просто удалил все файлы и запустил gc prune
После этого все работает просто отлично.
источник
Объяснение : Похоже, что ваши удаленные ветки репо (в Github / bitbucket) были удалены, хотя ваши локальные ссылки не были обновлены и указывают на несуществующие ссылки.
Чтобы решить эту проблему:
Для дополнительного чтения - ссылка на документацию Github :
источник
git fetch --prune
исправил эту ошибку для меня:Это предполагает, что ветка-нарушитель была удалена на удаленном компьютере.
источник
--prune
что я вижу. Также proTip: удалите ненужные пароли после вставки примеров.Если эта ошибка «невозможно обновить локальную ссылку» повторяется, даже после применения ответа Vojtech Vitek или Мишеля Крамера у вас может возникнуть неправильная ссылка на локальный И главный репозиторий.
В этом случае вы должны применить оба исправления без натяжения или толкания между ними ...
Постоянное разрешение для меня было достигнуто только после применения обоих исправлений перед push / pull.
источник
Чтобы ответить на этот вопрос очень коротко, эта проблема возникает, когда у вашего местного пользователя есть некоторая информация об удаленном, и кто-то меняет что-то, что делает удаленный и ваши изменения не синхронизированными.
Я получил эту проблему, потому что кто-то удалил удаленную ветку и снова создал с тем же именем.
Для решения таких проблем сделайте извлечение или выборку с пульта.
или если вы используете какой-либо графический интерфейс, сделайте выборку с пульта.
источник
Я был в состоянии работать с
источник
Попробуй это:
Branch_Name
ветвь, на которой вы сейчас находитесь.Если вы сделаете только a
git pull
, оно вытянет и все другие созданные имена ветвей.Так вот почему вы получаете это:
источник
Для меня у меня был локальный филиал,
feature/phase2
а удаленный был названfeature/phase2/data-model
. Причиной проблемы был конфликт имен, поэтому я удалил свою локальную ветку (вы можете переименовать ее, если в ней есть что-то, что вам нужно сохранить)источник
Если не
git gc --prune=now
поможет вам. (невезение, как я)Что я сделал, так это удалил проект локально и снова клонировал весь проект.
источник
Я использую Tower, и по какой-то причине мое имя папки было
.git/refs/remotes/origin/Github
. Изменение в нижний регистр.git/refs/remotes/origin/github
решило проблему.источник
У меня была такая же проблема. я следую за следующими шагами
1) переключите вашу ветку, у которой возникла проблема, на другую ветку
2) удалить эту ветку
3) оформить заказ снова.
Примечание: - Вы можете спрятать незафиксированные изменения и вернуть их снова.
источник
Я использовал,
git prune origin
и это сделало работу.источник
У меня была такая же проблема с обновлением композитора. Но для меня это сработало только после того, как я очистил кэш композитора и после удаления содержимого папки vendor:
источник
Возникла эта проблема при попытке клонирования из
git bundle
созданного файла, ни один из других ответов не сработал, потому что я не мог клонировать репозиторий (поэтому обgit gc
удалении / редактировании файлов не могло быть и речи).Был, однако, другой способ исправить это - исходный файл
.bundle
файла начинался с:Простое удаление четвертой строки с помощью vim устранило проблему.
источник
У меня была эта проблема при использовании SourceTree. Я попытался снова вытащить, и это сработало. Я думаю, что я слишком быстро колдовал (оформить заказ) :).
Моя ситуация немного отличается от ситуации с постером, потому что мой репозиторий был относительно кооперативным, без каких-либо явных искажений.
источник
источник
Столкнулся с той же проблемой, когда хранилище было удалено и создано с тем же именем. Это сработало только когда я переустановил удаленный URL, как показано ниже;
Проверьте удаленный URL:
Теперь все команды должны работать как обычно.
источник
Просто столкнулся с проблемой сегодня.
Метод устранения неполадок: с помощью SourceTree на серверах Windows вы можете попробовать запустить его как администратор. Это решает мою проблему «не удалось обновить локальную ссылку» в Atlassian Source Tree 2.1.2.5 на Windows Server 2012 R2 в домене.
Если вы можете слишком повторить эту ситуацию, это доказывает, что проблема вызвана проблемой разрешения. Лучше детализировать и найти основную причину - вероятно, некоторые конкретные файлы принадлежат другим пользователям и тому подобное - в противном случае есть нежелательный побочный эффект: вам придется запускать SourceTree в качестве Администратора до конца вечности.
источник
Записать конкретный случай, который может вызвать эту проблему.
Однажды я нажал на ветку с именем «feature / subfeature», имея ветку «feature» на пульте.
Эта операция работала нормально без каких-либо ошибок на моей стороне, но когда мои коллеги извлекли и / или вытащили какую-либо ветку, у всех них было одно и то же сообщение об ошибке
unable to update local ref
,cannot lock ref 'refs/remotes/origin/feature/subfeature
.Это было решено удалением
feature
ветки на remote (git push --delete origin feature
) и последующим запускомgit remote prune origin
репо моего коллеги, которое генерировало сообщения, включая* [pruned] origin/feature
.Итак, я предполагаю, что
git fetch
пытался создатьsubfeature
ref вfeature
папке внутри git (.git / ...), но создать папку не удалось, потому чтоfeature
уже был ref.источник
Эта проблема возникла, когда разработчик на Mac создал ветку с символом «>» в имени ветви.
Это вызвало проблемы в TeamCity и на локальных компьютерах под управлением Windows, работающих под управлением SourceTree. BitBucket пропустил его без проблем.
Для разрешения пользователь удалил ветку и пересоздал ее. Что было приятно и легко.
источник
Был тот же MSG, но с каталогом, получил сбой MSG на тяге.
git --prone мне тоже не помог. Оказывается, там был файл с тем же именем, что и каталог, созданный удаленно.
Пришлось зайти в .git \ logs \ refs \ remotes \ origin и стереть файл локали - потом вытащить снова, все хорошо.
источник