Git и неприятная "ошибка: невозможно заблокировать существующую информацию /refs fatal"

Ответ 1

Вы хотите попробовать:

git gc --prune=now

См. https://www.kernel.org/pub/software/scm/git/docs/git-gc.html

Ответ 2

Для меня это сработало:

git remote prune origin

Поскольку этот ответ, похоже, помогает многим людям, я немного углубился в то, что на самом деле происходит здесь. Для этого нужно удалить ссылки на удаленные ветки в папке .git/refs/remotes/origin. Так что это не повлияет на ваши локальные ветки и не изменит ничего удаленного, но обновит ваши локальные ссылки на удаленные ветки. Кажется, в некоторых случаях эти ссылки могут содержать данные, которые Git не может обработать правильно.

Ответ 3

Это случилось со мной, когда мой git remote (bitbucket.org) изменил свой IP-адрес. Быстрое исправление заключалось в удалении и повторном добавлении пульта, тогда все работало, как ожидалось. Если вы не знакомы с тем, как удалить и повторно добавить удаленный доступ в git, выполните следующие действия:

• Скопируйте URL-адрес SSH git вашего существующего пульта. Вы можете распечатать его на терминал с помощью этой команды:

  git remote -v

который выведет что-то вроде этого:

 origin [email protected]:account-name/repo-name.git (fetch)
 origin [email protected]:account-name/repo-name.git (push)

2. Удалите удаленный из локального репозитория git:

   git remote rm origin

3. Добавьте удаленный сервер обратно в локальное репо:

   git remote add origin [email protected]:account-name/repo-name.git

Ответ 4

Я исправил это, выполнив следующие

git branch --unset-upstream
rm .git/refs/remotes/origin/{branch}
git gc --prune=now
git branch --set-upstream-to=origin/{branch} {branch}
#or git push --set-upstream origin {branch}
git pull

Это предполагает, что ваши локальные и удаленные ветки выровнены, и вы просто получаете ошибку refs как не фатальную.

Ответ 5

Выполнение команды git update-ref -d refs/heads/origin/branch исправило это.

Ответ 6

Это, вероятно, разрешено к настоящему времени. Но вот что сработало для меня.

• Расположение:

  • Если заблокированный репозиторий находится на стороне сервера:

    • ssh в репозиторий git на сервере.
    • Вход как пользователь, который имеет разрешения на изменение репозитория и переход к репозиторию на вашем сервере.

  • Если заблокированный репозиторий только локальный:

    • Откройте консоль git и перейдите в каталог репозитория.

    • Запустите эту команду:

      git update-server-info
      

• Исправьте разрешения для вашего (удаленного или/или локального) репозитория, если вам нужно. В моем случае я должен был chmod до 777 и chown до apache:apache

• Попробуйте снова нажать из локального репозитория:

  git push
  

Ответ 7

У меня была эта проблема, потому что я был на ветке, имя которой было похоже на ветку восходящего потока. то есть ветка upstream называлась example-branch а моя локальная ветка называлась example-branch/backend. Решением было изменение названия моего локального ветки следующим образом:

git branch -m <new name goes here>

Ответ 8

Вот как это работает для меня.

• найдите файл блокировки Apache DAV на вашем сервере (например,/var/lock/apache2/DAVlock)
• удалить его
• воссоздайте его с разрешениями на запись для веб-сервера
• перезапустить веб-сервер

Еще более быстрая альтернатива:

• найдите файл блокировки Apache DAV на вашем сервере (например,/var/lock/apache2/DAVlock)
• Пустой файл: cat /dev/null > /var/lock/apache2/DAVlock
• перезапустить веб-сервер

Ответ 9

Это звучит как проблема с разрешениями - возможно ли, что вы открыли два окна, выполняющих отдельные права? Возможно, проверьте право собственности на папку .git.

Возможно, проверьте, открыта ли открытая блокировка файла, возможно, используйте lsof для проверки или эквивалент вашей ОС.

Ответ 10

В моем случае ветвь была перемещена в подкаталог, и каталог был вызван как ветка. Git был смущен этим. Когда я удалил локальную ветвь (в SourceTree с удалением правой кнопки мыши), все работает как обычно.

Ответ 11

Update:

Возможно, вам потребуется отредактировать файл ~/.netrc:

https://bugs.launchpad.net/ubuntu/+source/git-core/+bug/293553

Оригинальный ответ:

Почему вы отключили ssl? Я думаю, что это может быть связано с тем, что вы не можете нажать через https. Я вернул его и снова попытаюсь нажать:

git config –global http.sslVerify true

Ответ 12

У меня была эта проблема, когда я пытался создать новую ветвь функции, которая содержала имя старой ветки, например origin - branch1, и я хотел создать функцию branch1. Это было невозможно, но branch1/feature уже была.

Ответ 13

Убедитесь, что у вас (git процесс фактически) есть доступ к файлу .git/info/refs, и этот файл не заблокирован другим процессом.

Ответ 14

В случае bettercodes.org решение более поэтично - единственная проблема может быть в правах, назначенных членам проекта. У простых участников нет прав на запись! Убедитесь, что у вас есть права модератора или администратора. Разумеется, это необходимо установить на bestcodes.org в настройках проекта администратором.

Ответ 15

Я видел эту ошибку при попытке запустить git filter-branch для отсоединения многих подкаталогов в новый отдельный репозиторий (как в этом ответе).

Я перепробовал все вышеперечисленные решения, и ни одно из них не сработало. В конце концов я решил, что мне не нужно сохранять все эти теги в новой ветке, и просто запустил:

git remote remove origin
git tag | xargs git tag -d
git gc --prune=now
git filter-branch --index-filter 'git rm --cached -qr --ignore-unmatch -- . && git reset -q $GIT_COMMIT -- apps/AAA/ libs/xxx' --prune-empty -- --all

Ответ 16

В моем случае это было связано с именем ветки, которое я уже создал.
Сначала я создал ветку с некоторым именем, которое наверняка не должно существовать, например:

git checkout -b some_unknown_branch

затем я очистил все остальные мои ветки, потому что они были просто ненужным мусором.

git branch | grep -v \* | grep -v master | xargs git branch -D

и затем переименовал мою ветку в имя, которое я намеревался, например:

git checkout -m my_desired_branch_name