GIT en NASTY “FOUT: kan bestaande informatie / refs fatal”

Na klonering van Remote Git Repository (bij Bettercodes)
Ik heb enkele wijzigingen aangebracht, gecommoreerd
en probeerde te duwen:

git push origin master

Fouten met:

FOUT: kan bestaande informatie / referentie niet vergrendelen
FATAL: GIT-HTTP-PUSH FAILED

Deze zaak beschouwt reeds bestaande repository.

wat ik eerder deed, was:

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

Bij ‘Bettercodes’ heb ik geen toegang tot Git Log.

Ik gebruik Windows.
De gedetailleerde fout was:

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

Ik heb eerder gekloneerd, vervolgens de code gewijzigd en toegewijd.

Antwoord 1, Autoriteit 100%

Voor mij werkte dit (zal niet veranderen in de afstandsbediening):

git remote prune origin

Sinds dit antwoord lijkt veel mensen te helpen, ik groef een beetje in wat er hier gebeurt. Wat dit doet, is verwijzingen naar externe filialen in de map .git/refs/remotes/origin.

Dus dit heeft geen invloed op uw lokale takken en het zal niets op afstand wijzigen , maar het zal de lokale referenties bijwerken die u hebt op afstandsbediening. Het lijkt in sommige gevallen deze referenties kunnen data-git bevatten, kan niet correct aanpakken.

Antwoord 2, Autoriteit 56%

U wilt proberen:

git gc --prune=now

Zie https://www.kernel.org/pub/software/ SCM / GIT / DOCS / GIT-GC.HTML

Antwoord 3, Autoriteit 21%

Dit is me overkomen toen mijn git-afstandsbediening (Bitbucket.org) hun IP-adres heeft gewijzigd. De snelle oplossing was om de afstandsbediening te verwijderen en opnieuw te voegen, vervolgens werkte alles zoals verwacht. Als u niet bekend bent met het verwijderen en opnieuw toevoegen van een afstandsbediening in GIT, zijn hier de stappen:

1. Kopieer de SSH GIT-URL van uw bestaande afstandsbediening. U kunt het op de terminal afdrukken met behulp van deze opdracht:

   git remote -v

die iets als volgt afdrukt:

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

2. Verwijder de afstandsbediening van uw lokale Git Repo:

   git remote rm origin

3. Voeg de afstandsbediening toe terug aan uw lokale repo:

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

Antwoord 4, Autoriteit 6%

Dit is wat ik deed om van alle LOCK Ref-problemen af ​​te komen:

git gc --prune=now
git remote prune origin

Dit is waarschijnlijk wat u alleen hoeft te doen.

Meer over git gcOpdracht hier: https: // git- scm.com/docs/git-gc

Meer over git remote prunehier: https://git-scm.com/docs/git-remote#documentation/git-remote.txt-empruneem

Antwoord 5, Autoriteit 6%

Running Commando git update-ref -d refs/heads/origin/branchFixed It.

Antwoord 6, Autoriteit 3%

Wat voor mij werkte, was:

1. Verwijder .git/logs/refs/remotes/origin/branch
2. Verwijder .git/refs/remotes/origin/branch
3. Voer git gc --prune=now

uit

Meer over de opdracht git gchier: https://git- scm.com/docs/git-gc

Antwoord 7, autoriteit 3%

Ik heb dit opgelost door het volgende te doen

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

Dit ervan uitgaande dat uw lokale en externe branches zijn uitgelijnd en dat u de refs-fout alleen als niet-fataal krijgt.

Antwoord 8, autoriteit 2%

Voordat u gaat trekken, moet u uw lokale wijzigingen opschonen. volgende opdracht help me om op te lossen.

git remote prune origin

en daarna

git pull origin develop

Hopelijk helpt dit!

Antwoord 9, autoriteit 2%

Ik had dit probleem omdat ik in een vertakking zat die een vergelijkbare naam had als een stroomopwaartse vertakking. d.w.z. de upstream-tak heette example-branchen mijn lokale branch heette example-branch/backend. De oplossing was om de naam van mijn lokale vestiging als volgt te veranderen:

git branch -m <new name goes here>

Antwoord 10

Dit is waarschijnlijk inmiddels opgelost. Maar dit is wat voor mij werkte.

1. Locatie:

   • Als de vergrendelde repository zich aan de serverzijde bevindt:

     1. ssh naar je git-repository op de server.
     2. Log in als gebruiker die rechten heeft om de repository te wijzigen en navigeer naar de repository op uw server.

   • Als de vergrendelde repository alleen lokaal is:

     1. Open de git-console en navigeer naar de repository-map.

     2. Voer deze opdracht uit:

        git update-server-info
        

2. Repareer indien nodig de rechten op uw (externe en/of lokale) repository. In mijn geval moest ik chmodnaar 777en chownnaar apache:apache

3. Probeer opnieuw te pushen vanuit de lokale repository:

   git push
   

Antwoord 11

Zo werkt het voor mij.

1. zoek het Apache DAV-vergrendelingsbestand op uw server op (bijv. /var/lock/apache2/DAVlock)
2. verwijder het
3. maak het opnieuw met schrijfrechten voor de webserver
4. start de webserver opnieuw

Nog sneller alternatief:

1. zoek het Apache DAV-vergrendelingsbestand op uw server op (bijv. /var/lock/apache2/DAVlock)
2. Leeg het bestand: cat /dev/null > /var/lock/apache2/DAVlock
3. start de webserver opnieuw

Antwoord 12

Dit klinkt als een machtigingsprobleem – is het mogelijk dat u twee vensters open had staan die met afzonderlijke rechten werden uitgevoerd? Controleer misschien het eigendom van de .git-map.

Controleer misschien of er een openstaande bestandsvergrendeling is geopend, gebruik misschien lsof om te controleren of het equivalent voor uw besturingssysteem.

Antwoord 13

In mijn geval werd een vertakking naar een submap verplaatst en werd de map de vertakking genoemd. Git was daardoor in de war. Toen ik de lokale branch verwijderde (in SourceTree gewoon met de rechtermuisknop op delete) werkte alles zoals gewoonlijk.

Antwoord 14

Bijwerken:

Mogelijk moet u uw ~/.netrc-bestand bewerken:

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

Oorspronkelijk antwoord:

Waarom heb je ssl uitgeschakeld? Ik denk dat dit te maken kan hebben met het feit dat je niet kunt pushen via https. Ik zou het terugzetten en opnieuw proberen te duwen:

git config –global http.sslVerify true

Antwoord 15

In mijn geval deed ik na het ontvangen van dit bericht de opdracht afrekenenen kreeg dit bericht:

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

Na het uitvoeren van deze opdracht was ik weer normaal.

Antwoord 16

Voer git fetch --alluit vóór git pull. Dat zou het probleem moeten oplossen.

Antwoord 17

Ik had dezelfde foutmelding, de hoofdoorzaak was een herschrijving van de geschiedenis (hernoemen van takken).

Dat werkte voor mij:

git remote prune origin

Bron: https://codedaily.in/git-error-cannot- lock-refs/

Antwoord 18

Controleer of je (git-proces feitelijk) toegang hebt tot bestand .git/info/refsen dat dit bestand niet is vergrendeld door een ander proces.

Antwoord 19

Ik had dit probleem toen ik probeerde een nieuwe feature branch te maken die de naam van de oude branch bevatte, b.v. origin – branch1 en ik wilde branch1-feature maken.
Het was niet mogelijk, maar branch1/feature was er al.

Antwoord 20

In mijn geval moest ik handmatig oude tags verwijderen die op afstand waren verwijderd.

Antwoord 21

In mijn geval was het verbonden met de filiaalnaam die ik al had gemaakt.

Om het probleem op te lossen heb ik een branch gemaakt met de naam die zeker niet zou moeten bestaan, zoals:

git checkout -b some_unknown_branch

Dan heb ik al mijn andere takken (niet actief) gewist omdat ze gewoon onnodig afval waren.

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

en vervolgens mijn huidige tak hernoemd met de naam die ik heb bedacht, zoals:

git checkout -m my_desired_branch_name

Antwoord 22

Afgezien van de vele beantwoorden die al aan deze vraag zijn geleverd, een eenvoudige controle op de lokale repotakken die in uw machine bestaan ​​en zij die niet in de afstandsbediening, zullen helpen. In welk geval u niet de

gebruikt

Git snoei

opdracht zoals velen hebben gesuggereerd.

Verwijder eenvoudig de lokale tak

git branch -d <branch name without a remote tracking branch by the same name>

Zoals te zien is in de bijgevoegde schermafbeelding met -d om Delete te forceren als u er zeker van bent dat een lokale tak geen op afstand gevolgd is.

Antwoord 23

Ik had een typisch Mac-gerelateerd probleem dat ik niet kon oplossen met de andere voorgestelde antwoorden.

Mac’s standaard bestandssysteeminstelling is dat het geval ongevoelig is.

In mijn geval is een collega duidelijk vergeten een hoofdletter te creëren voor een filiaal d.w.z.

Testbranch / ID-1
vs.
Testbranch / ID-2

Voor het MAC-bestandssysteem (Ja, kan het anders worden geconfigureerd) Deze twee takken zijn hetzelfde en in dit geval krijgt u alleen een van de twee mappen. En voor de resterende map krijg je een foutmelding.

In mijn geval, het verwijderen van de submap in kwestie in .git / logs / ref- / afstandsbediening / oorsprong opgelost het probleem, omdat de betreffende tak al is samengevoegd.

Antwoord 24

Deze fout kwam eraan

git fetch

maar in mijn geval wilde ik alleen de update van de hoofdbranch die gedaan kan worden met

git fetch origin main

Geen oplossing om het ref-probleem te vergrendelen, maar het heeft me geholpen het probleem te vermijden 😛

Antwoord 25

In het geval van bettercodes.org is de oplossing poëtischer – het enige probleem kan liggen in de rechten die aan de projectleden zijn toegewezen. Eenvoudige leden hebben geen schrijfrechten! Zorg ervoor dat u over de moderator- of beheerdersrechten beschikt. Dit moet natuurlijk door een beheerder worden ingesteld op bettercodes.org bij de projectinstellingen.

Antwoord 26

Ik zag deze fout bij het uitvoeren van git filter-branchom veel submappen los te koppelen in een nieuwe, aparte repository (zoals in dit antwoord).

Ik heb alle bovenstaande oplossingen geprobeerd en geen enkele werkte. Uiteindelijk besloot ik dat ik mijn tags niet zo erg hoefde te bewaren in de nieuwe branch en liep gewoon:

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

Antwoord 27

Bij mij gebeurde het wanneer ik een nieuwe branch probeer te maken met een naam zoals deze:

master/pre-upgrade

het veranderen in een andere naam zoals:

pre-upgrade/master

het is gelukt!

Antwoord 28

Als je in de gelukkige positie verkeert dat je geen lokaal werk hebt om te plegen/push en tijd hebt om koffie te halen, kun je eenvoudig je lokale kopie van de repo verwijderen en opnieuw klonen

Antwoord 29

voor mij is het verwijderen van .git/info/refeen schot in de roos. Er zou geen ref-bestand moeten zijn als git niet actief is. Maar in mijn geval was er een om welke reden dan ook en veroorzaakte het probleem.

Als je het bestand verwijdert, worden je lokale commits of branches niet verwijderd.