Git i paskudny „błąd: nie można zablokować istniejących informacji / odnośników krytycznych”

Po klonowaniu ze zdalnego repozytorium git (w lepszych kodach) dokonałem pewnych zmian, zatwierdziłem i próbowałem wypchnąć:

git push origin master

Błędy związane z:

błąd: nie można zablokować istniejących informacji / odnośników
krytycznych: błąd git-http-push nie powiódł się

Ten przypadek dotyczy już istniejącego repozytorium.

To, co robiłem wcześniej, to:

1. git config –global http.sslVerify false
2. git init
3. git remote add [url]
4. git clone
5. zmienić dane
6. git commit

W „bettercodes” nie mam dostępu do dziennika git.

Korzystam z systemu Windows. Szczegółowy błąd to:

C:\MyWorkStuff\Projects\Ruby\MyProject\>git push origin master
Unable to create branch path https://user:[email protected]/myproject/info/
error: cannot lock existing info/refs
fatal: git-http-push failed

Sklonowałem wcześniej, potem zmieniłem kod i zatwierdziłem.

Dla mnie to zadziałało:

git remote prune origin

Ponieważ wydaje się, że ta odpowiedź pomaga wielu ludziom, wgłębiłem się nieco w to, co się tutaj naprawdę dzieje. Spowoduje to usunięcie odniesień do zdalnych gałęzi w folderze .git/refs/remotes/origin. Nie wpłynie to więc na oddziały lokalne i nie zmieni niczego zdalnego, ale zaktualizuje lokalne odwołania do oddziałów zdalnych. Wydaje się, że w niektórych przypadkach te odwołania mogą zawierać dane, których Git nie może poprawnie obsłużyć.

Chcesz spróbować:

git gc --prune=now

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

Stało się tak, gdy mój git remote (bitbucket.org) zmienił adres IP. Szybka poprawka polegała na usunięciu i ponownym dodaniu pilota, a następnie wszystko działało zgodnie z oczekiwaniami. Jeśli nie wiesz, jak usunąć i ponownie dodać pilota w git, wykonaj następujące czynności:

1. Skopiuj adres URL git SSH istniejącego pilota. Możesz wydrukować go na terminalu za pomocą tego polecenia:

   git remote -v

który wydrukuje coś takiego:

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

2. Usuń pilota z lokalnego repozytorium git:

   git remote rm origin

3. Dodaj pilota z powrotem do lokalnego repozytorium:

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

Uruchomione polecenie git update-ref -d refs/heads/origin/branchnaprawiło to.

Naprawiłem to, wykonując następujące czynności

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

Zakładając, że lokalne i zdalne gałęzie są wyrównane, a błąd refs pojawia się jako niekrytyczny.

Miałem ten problem, ponieważ byłem w oddziale, który miał podobną nazwę do oddziału. tzn. wezwano gałąź upstream example-branchi moja gałąź lokalna example-branch/backend. Rozwiązaniem była zmiana nazwy mojego lokalnego oddziału w następujący sposób:

git branch -m <new name goes here>

Prawdopodobnie problem został już rozwiązany. Ale oto, co zadziałało dla mnie.

1. Lokalizacja:

   • Jeśli zablokowane repozytorium znajduje się po stronie serwera:

     1. ssh do Twojego repozytorium git na serwerze.
     2. Zaloguj się jako użytkownik, który ma uprawnienia do modyfikowania repozytorium i przejdź do repozytorium na serwerze.

   • Jeśli zablokowane repozytorium jest tylko lokalne:

     1. Otwórz konsolę git i przejdź do katalogu repozytorium.

     2. Uruchom to polecenie:

        git update-server-info
        

2. W razie potrzeby napraw uprawnienia w swoim (zdalnym lub / i lokalnym) repozytorium. W moim przypadku musiałem chmodsię 777i chowndoapache:apache

3. Spróbuj wypchnąć ponownie z lokalnego repozytorium:

   git push
   

Dla mnie zadziałało:

1. Usunąć .git/logs/refs/remotes/origin/branch
2. Usunąć .git/refs/remotes/origin/branch
3. Biegać git gc --prune=now

Tak to dla mnie działa.

1. wyszukaj plik blokady Apache DAV na serwerze (np. / var / lock / apache2 / DAVlock)
2. Usuń to
3. utwórz go ponownie z uprawnieniami do zapisu dla serwera WWW
4. zrestartuj serwer WWW

Jeszcze szybsza alternatywa:

1. wyszukaj plik blokady Apache DAV na serwerze (np. / var / lock / apache2 / DAVlock)
2. Opróżnij plik: cat /dev/null > /var/lock/apache2/DAVlock
3. zrestartuj serwer WWW

To brzmi jak problem z uprawnieniami - czy to możliwe, że masz otwarte dwa okna, uruchamiane z osobnymi prawami? Być może sprawdź własność folderu .git.

Być może sprawdź, czy jest otwarta zaległa blokada pliku, może użyj lsof, aby sprawdzić, lub odpowiednika dla twojego systemu operacyjnego.

W moim przypadku gałąź została przeniesiona do podkatalogu, a katalog został nazwany jako gałąź. Git był tym zmieszany. Kiedy usunąłem lokalny oddział (w SourceTree tylko prawym przyciskiem myszy usuń) wszystko działało jak zwykle.

W moim przypadku po otrzymaniu tej wiadomości wykonałem polecenie kasy i otrzymałem tę wiadomość:

Your branch is based on 'origin/myBranch', but the upstream is gone.
  (use "git branch --unset-upstream" to fixup)

Po uruchomieniu tego polecenia wróciłem do normy.

Aktualizacja:

Może być konieczna edycja pliku ~ / .netrc:

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

Oryginalna odpowiedź:

Dlaczego wyłączyłeś ssl? Myślę, że może to mieć związek z tym, że nie możesz przesyłać danych przez https. Odłożyłbym to z powrotem i spróbowałem ponownie:

git config –global http.sslVerify true

Sprawdź, czy masz (proces git) dostęp do pliku .git/info/refsi czy ten plik nie jest zablokowany przez inny proces.

Miałem ten problem, kiedy próbowałem utworzyć nową gałąź funkcji, która zawierała nazwę starej gałęzi, np. Origin - gałąź1 i chciałem utworzyć funkcję gałąź1. Nie było to możliwe, ale funkcja branch1 / już była.

W moim przypadku musiałem ręcznie usunąć stare tagi, które zostały usunięte zdalnie.

W moim przypadku było to związane z nazwą oddziału, którą już utworzyłem.

Aby rozwiązać ten problem, utworzyłem gałąź o nazwie, która z pewnością nie powinna istnieć, na przykład:

git checkout -b some_unknown_branch

Następnie wyczyściłem wszystkie inne gałęzie (nieaktywne), ponieważ były to niepotrzebne śmieci.

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

a następnie zmieniłem nazwę mojej obecnej gałęzi na nazwę, którą zamierzałem, na przykład:

git checkout -m my_desired_branch_name

W przypadku bettercodes.org rozwiązanie jest bardziej poetyckie - jedynym problemem mogą być prawa przypisane członkom projektu. Prosti członkowie nie mają prawa zapisu! Upewnij się, że masz uprawnienia moderatora lub administratora. Oczywiście administrator musi to ustawić na stronie bettercodes.org w ustawieniach projektu.

Widziałem ten błąd podczas próby uruchomienia, git filter-branchaby odłączyć wiele podkatalogów do nowego, osobnego repozytorium (jak w tej odpowiedzi ).

Wypróbowałem wszystkie powyższe rozwiązania i żadne z nich nie działało. W końcu zdecydowałem, że nie muszę zachowywać wszystkich moich tagów w nowej gałęzi i po prostu uruchomiłem:

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