Hoe repo opschonen, indien gefaseerde bestanden gemarkeerd als gewijzigd?

Na

git reset --hard

Ik snap

Encountered 7 file(s) that should have been pointers, but weren't:

Het uitvoeren van git clean -fdxhelpt ook niet.

Antwoord 1, autoriteit 100%

Zoals Travis Heetervermeld in zijn antwoord, Probeer de volgende opdrachtreeks:

git lfs uninstall
git reset --hard
git lfs install
git lfs pull

Als dit niet werkt (omdat dit bij mij niet werkte), kan de volgende hack werken:

git rm --cached -r .
git reset --hard
git rm .gitattributes
git reset .
git checkout .

Dit werkte voor mij!

Antwoord 2, autoriteit 44%

Ik had deze exacte fout met sommige bestanden die waren opgeslagen met git-LFS en op dezelfde manier opgelost als ik een door linnending geïnduceerde borked index heb opgelost .

Wis de cache en voer een harde reset uit:

git rm --cached -r .
git reset --hard

Dit was aanzienlijksneller dan een nieuwe kloon voor mij vanwege de enorme git-LFS-bestanden in mijn repo.

Antwoord 3, autoriteit 22%

Sinds git lfs 2.5.0 is er een nieuwe opdracht beschikbaar die dit gemakkelijker maakt (docs):

git lfs migrate import --no-rewrite "broken file.jpg" "another broken file.png" ...

Dit “migreert” bestanden naar git lfs, dat in lfs zou moeten staan ​​volgens .gitattributes, maar dat momenteel niet is (wat de reden is voor je foutmelding).

--no-rewritevoorkomt dat git dit toepast op oudere commits, het creëert in plaats daarvan een enkele nieuwe commit.

Gebruik -m "commitmessage"om een ​​commitbericht voor die commit in te stellen.

Antwoord 4, autoriteit 20%

Het probleem komt van de mismatch tussen de bestandstypes die zijn gemarkeerd als te worden gevolgd door git LFS in de .gitattributesen enkele overeenkomende bestanden die al onder conventioneel niet-LFS-versiebeheer staan.

Dus de eenvoudigste oplossing hier is om het bestand .gitattributeseven te verwijderen:

git rm .gitattributes
git reset .
git checkout .

Daarna kunt u bij elk ander filiaal afrekenen.

Nog een advies: als je een nieuw bestandstype toevoegt aan git LFS, doe dit dan liever niet met de hand door de .gitattributesaan te passen, maar b.v. door te rennen:

git lfs track PATTERN

waar PATTERN het patroon is voor overeenkomende bestanden, bijvoorbeeld *.so

Op deze manier worden alle reeds niet-LFS-versiebestanden die overeenkomen met het nieuwe volgpatroon als vuil gemarkeerd en kunnen ze eenvoudig worden toegevoegd, d.w.z. geconverteerd naar git LFS (bestandsaanwijzers).

Antwoord 5, autoriteit 12%

Dit kan gebeuren wanneer je een checkout uitvoert die bestanden bevat die door LFS zouden moeten worden gevolgd, zoals gespecificeerd in .gitattributes, maar op de een of andere manier zijn ze in plaats daarvan rechtstreeks vastgelegd. Hoogstwaarschijnlijk heb je een ander programma dat je repository beheert, zoals een git GUI of IDE.

Dit kan frustrerend zijn omdat deze bestanden uit het niets verschijnen en ervoor zorgen dat u niet kunt afrekenen. Zodra u uw wijzigingen opbergt, komen ze terug! Als je in deze situatie vastloopt, is een snelle oplossing om deze wijzigingen door te voeren in een tijdelijke branch, zodat je weer kunt afrekenen.

Om dit probleem echt op te lossen, moet u ervoor zorgen dat u de bestanden als LFS-aanwijzers hebt vastgelegd. Dit zou zo simpel moeten zijn als het gebruik van git add. Controleer je werk met git lfs statusvoordat je het vastlegt. git lfs ls-fileslaat zien welke bestanden LFS beheert.

git lfs statusis misleidend omdat het Git LFS objects to be committedterwijl het echt alle wijzigingen opsomt. Bestanden waarvan u verwacht dat ze worden bijgehouden door LFS, moeten iets lezen als (LFS: c9e4f4a)of (Git: c9e4f4a -> LFS: c9e4f4a)en niet (Git: c9e4f4a).

Bij wijze van voorbeeld vond ik dit een probleem bij het toevoegen van afbeeldingsitems via Xcode 9.2, waar ik “CalendarChecked.png” heb toegevoegd die automatisch werd toegevoegd:

$ git status
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)
    new file:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
    modified:   Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png
$ git lfs status
Git LFS objects to be committed:
    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (Git: c9e4f4a)
Git LFS objects not staged for commit:
    Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (File: c9e4f4a)
$ git add Example/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png`
$ git lfs status
Git LFS objects to be committed:
    Empty/Empty/Assets.xcassets/CalendarChecked.imageset/CalendarChecked.png (LFS: c9e4f4a)
Git LFS objects not staged for commit:
$

Antwoord 6, autoriteit 10%

Geen van deze oplossingen werkte voor mij, maar ik heb een paar bronnen bij elkaar gezocht om dit allemaal opgelost te krijgen.

1. Duw alle wijzigingen die u niet kwijt wilt raken

   Als je kunt… Zo niet, of als je niet geïnteresseerd bent in je wijzigingen, druk dan op.

2. Stop alles

   SourceTree, alle servers, bestandsverkenners en browsers. Soms werkt dit spul niet als het ergens anders wordt gebruikt. Stop er bij twijfel mee – hiermee is het beter om te overdrijven.

   Ga ook naar Taakbeheer en sluit alle bash.exe-processen geforceerd af. Git Bash heeft de neiging om bestanden open te houden nadat je het venster hebt gesloten.

3. Open een opdrachtvenster (of terminal)

   cdnaar uw lokale opslagplaats.

4. Verwijder lfs

   > git lfs uninstall

   Dan staat er iets als:

   Hooks for this repository have been removed.
   Global Git LFS configuration has been removed.
   

5. Resetten

   > git reset --hard

   Er zal waarschijnlijk veel output nodig zijn…

6. Installeer lfs

   opnieuw

   > git lfs install

   Dit kan opnieuw zeggen dat het bestanden heeft gevonden die aanwijzers hadden moeten zijn, maar dat niet waren. Goed, ga zo door!

7. Trek met lfs

   > git lfs pull

   Hopelijk zal het trekken met lfs de bestanden overschrijven die borked zijn.

   Een paar van mijn bronnen zeiden dat hun repo op dat moment weer werkte, maar ik persoonlijk niet. Je kunt SourceTree of wat dan ook openen om te controleren als je wilt, maar het kan zijn dat je bovenaan moet beginnen als het niet werkt.

8. Migreren

   Het kernprobleem hier is dat lfs, in plaats van het downloaden van grote bestanden zoals audio, video, afbeeldingen – alles groter dan 1Mb – het gewoon naar hen verwijst op een server. Dit is handig als je een heleboel grote bestanden hebt, je hoeft niet al die dingen naar beneden te halen. Uw lokale repo is dus kleiner en wendbaarder. Echter, door omstandigheden waar ik niet zeker van ben, lijkt het mogelijk om de wijzers te corrumperen. Ik weet zeker dat dit een probleem is waar de lfs-mensen van op de hoogte zijn en aan werken, maar voor nu moeten we het zelf oplossen.

   Wat we tot nu toe hebben gedaan is

   • verwijder lfs
   • alles verwijderen
   • installeer lfs

   opnieuw

   • aan alles trekken

   Dus nu hebben we al deze dingenin onze map die ofwel bestandenof verwijzingen naar bestandenzijn, en lfsmoet uitzoeken of bestanden pointers moeten zijn en vice versa. En hopelijk hebben we door de bovenstaande stappen uit te voeren de beschadigde aanwijzers verwijderd. Dus we gaan migrateuitvoeren om de procedure te starten die door de bestanden op de repo gaat, en als ze groter zijn dan 1Mb, zal lfs ze vervangen door een aanwijzer.

   > git lfs migrate

9. Meer fouten

   Hier is een punt waarop anderen zijn gestopt en zeiden dat ze weer aan het werk waren, maar ik niet. Ik kreeg een foutmelding:

   Fout in git rev-list… exit status 128 fataal: slechte revisie ‘…v1.0.0‘

   @guneyozsan op een github-helppagina, plaatste dit laatste stukje van de puzzel, ook al loste het zijn probleem niet op.

   > git lfs migrate info --include-ref=v1.0.0

   Merk op dat de versie overeenkomt met de versie met een fout – v1.0.0. Je moet v1.0.0vervangen door de versie die je in je fout hebt gekregen.

   Ik heb geen bron gevonden waarom deze fout optreedt, maar ik vermoed dat het lfs-versienummer gegenereerd door migrateop uw lokale opslagplaats niet overeenkomt met de bronversie. Voor mij begon dit allemaal toen SourceTree crashte tijdens een push en ik een herstart van de machine dwong, en wanneer dat gebeurt, weet lfs niet hoe ermee om te gaan, dus het blijft gewoon vastzitten in deze lus waar het probeert te updaten, maar het kan de beschadigde gegevens niet lezen. Vandaar de langdurige probleemoplossing.

10. Opbergen en trekken

Als je SourceTree opent, zul je waarschijnlijk zien dat het al je bestanden weer wil toevoegen. Doe dat niet. Stash, dan trekken.

En boem, hopelijk is de horror voorbij. Zo niet, dan deze git hub-paginaof dezekan je misschien meer helpen, maar dit is wat voor mij werkte.

Antwoord 7, autoriteit 3%

Zorg ervoor dat git lfsversie 2.5 of hoger is geïnstalleerd (download hier).

Controleer of je de git lfs-versie gebruikt die je hebt gedownload (2.7.2 voor mij):

>git lfs version
git-lfs/2.7.2

Uitvoeren:

git lfs migrate import --fixup --everything

Trek aan je branch en los eventuele merge-conflicten op.

Gevonden in deze github-opmerking.

Antwoord 8

Een mogelijke oorzaak voor deze fout is vanwege git LFS-gerelateerde wijzigingen in .gitattributesdie van invloed zijn op reeds toegevoegde bestanden in een repo.

(Ik ben niet zeker van de exacte stappen om te reproduceren, maar het probleem leek op te treden toen ik een bestand aanraakte dat onlangs werd beïnvloed door de .gitattributes dat eerder was vastgelegd als een niet-LFS-bestand dat nu een LFS-bestand. Het probleem leek verergerd door het wisselen van branch, of maakte het in ieder geval onmogelijk om van branch te wisselen totdat het probleem was opgelost.)

In dit geval heb ik de onderstaande stappen gebruikt om te voorkomen dat deze fout herhaaldelijk optreedt.

1. Los het probleem op voor de branch waar u zich bevindt door een van de andere antwoorden hier te volgen (bijv. om de cache te wissen en opnieuw in te stellen. Ik vond BheeMa’s antwoordom effectief te zijn.)
2. Ga naar je hoofdbranch, en zorg ervoor dat er niets te committen is met git status
3. Git dwingen om wijzigingen in git-kenmerken opnieuw te controleren en “opnieuw toe te passen”

Van Het antwoord van Ratata Tatain Hoe u wijzigingen aanbrengt in .gitattributes)

git rm --cached -r .
 git add -A

Waarschuwing: zorg ervoor dat u in stap 2 niets hoeft vast te leggen, aangezien de bovenstaande stappen alle bestanden zullen toevoegen die nog niet eerder geversied waren

4. Verifieer de resultaten met git status(het zou alleen relevante bestanden moeten hebben gewijzigd om LFS-pointers te worden, dwz bestanden die mogelijk de fout “aangetroffen bestanden die pointers hadden moeten zijn” kunnen veroorzaken) en commit-wijzigingen
5. (Optioneel, merge/rebase deze fix naar alle andere branches indien mogelijk. Anders zou deze fout opnieuw kunnen verschijnen bij het overschakelen naar die branches. Merk op dat het nodig kan zijn om de initiële fix voor elke branch te herhalen zoals in stap 1 om veilig te zijn, hoewel het ok zou kunnen zijn om de getroffen bestanden te committen.)

Antwoord 9

Dit laat nog maar een keer zien wat een stapel honden**** GIT-LFS is.

Je kunt in deze situatie komen als:

1. Het bestand staat in common-base-branchen niet in LFS
2. In een branch lfs-branchgebaseerd op common-base-branchis het bestand verplaatst naar LFS
3. In een andere branch non-lfs-branchook gebaseerd op common-base-branch, is het bestand aangepast.

Of anders:

1. Het bestand bevindt zich NIET in common-base-branch
2. In een branch lfs-branchgebaseerd op common-base-branch, is het bestand toegevoegd aan LFS
3. In een andere branch non-lfs-branchook gebaseerd op common-base-branch, is het bestand toegevoegd (maar niet aan LFS.

In beide gevallen krijg je dit soort fouten wanneer je non-lfs-branchprobeert samen te voegen met lfs-branch.

Je kunt je afvragen waarom dit überhaupt zou moeten gebeuren, maar het antwoord is dat veel software door meer dan één persoon is ontwikkeld (daarom heb je in de eerste plaats versiecontrolesystemen zoals GIT), en mensen praten niet altijd met elkaar, of LFS wordt later in de geschiedenis van een project geïntroduceerd in een feature branch, terwijl de “normale” ontwikkeling in andere branches nog steeds doorgaat.

Dit is een legitieme merge-conflictsituatie, geen bug of corrupte werkmap of wat dan ook (zoals sommige van de andere antwoorden suggereren).GIT-LFS gaat er gewoon slecht mee om.

Wat u nu wilt doen, is ervoor zorgen dat de juiste versie van de conflicterende bestanden naar GIT-LFS gaat, dus u kunt een antwoord op deze vraag kiezen dat precies dat doet… (TODO: link invoegen naar minstens één antwoord dat werkt)

Antwoord 10

Het geaccepteerde antwoord werkte voor mij, maar het zou alleen werken als ik de commando’s handmatig typte, ik slaap tussen elk commando en nu werkt het als een bash-script:

git rm --cached -r .
sleep 1
git reset --hard
sleep 1
git rm .gitattributes
sleep 1
git reset .
sleep 1
git checkout .

Antwoord 11

Het volgende proces voegt een commit toe die alle binaire bestanden die lfs-pointers zouden moeten zijn, vervangt door lfs-pointers.

1. Reinig werkkopie volledig. Samen met de force add hieronder voorkomt dit dat bestanden worden toegevoegd of verwijderd vanwege .gitignore-patronen.

   git clean -dfx
   git reset --hard
   git checkout -- .
   

2. Verwijder voor alles toevoegen aan verzamelgebied. Werkkopie wordt niet aangeraakt.

   git rm --cached -r .
   

3. Alle bestanden van werkkopie opnieuw gelezen. Dit zal in feite de vorige opdracht ongedaan maken, maar lfs-filters opnieuw evalueren. Gebruik -f om .gitignore te negeren. Alle aanwezige bestanden zijn eerder ingecheckt en zouden opnieuw moeten worden toegevoegd.

   git add -f .
   

4. Uw staging-gebied mag nu alleen de binaire bestanden bevatten die eerder de foutmelding ‘hadden pointers’ moeten zijn.

   git commit -m "moved files to lfs"
   

Antwoord 12

Als je gewoon weg wilt van die slechte commit, kun je teruggaan naar master door

git reset --soft origin/master
git reset --hard

Dan ben je vrij van de vervelende 7 niet-LFS-bestanden 🙂

Antwoord 13

Dit is het probleem dat ik tegenkwam:

Stel dat je een branch hebt gemaakt en dat je op de een of andere manier bestanden hebt vastgelegd als niet-LFS. Dus toen probeerde je het te corrigeren door later de LFS-versie van de bestanden op dezelfde branch te committen. U kunt nu echter niet rebasen of squashen, omdat u tijdens het rebasen steeds de foutmelding “bestanden die aanwijzers hadden moeten zijn maar niet waren” tegenkomt.

Oplossen met git reset --soft: https://stackoverflow.com/a/5201642/ 2516916

Antwoord 14

In mijn geval was het één bestand onder lfs-regels (ik neem aan dat het is ingecheckt zonder dat lfs is geïnstalleerd of zoiets).

Dus ik vond de extensie in het .gitattributes-bestand en becommentarieerde deze regel als

#*.7z filter=lfs diff=lfs merge=lfs -text

deze .gitattributes opgeslagen en git statusgaf geen problemen.

Daarna heb ik deze regel verwijderd (verwijderd #), opgeslagen .gitattributes en git statusgeeft nog steeds geen problemen.

Antwoord 15

Als het duidelijk een fout is die uit het niets opduikt, doen we dit in ons team:

1. Lfs uitschakelen voor dat specifieke typebestand (wijzigen van .gitattributes of via SourceTree-menu’s)

2. De wijziging zal verdwijnen en u zult in plaats daarvan een wijziging zien op .gitattributes

3. Verwijder het probleem:

   3.1 Een oplossing is om git reset –hard uit te voeren. Een andere manier, wijzigingen negeren. Soms verschijnt het bestand niet meer.

   3.2.1 Als de vorige oplossing niet werkt, herhaal dan 1 en 2. Zorg er dan voor dat deze branch waarin je zit (A) al alles heeft gecommit en gepusht behalve die vervelende bestanden. Leg vervolgens uw wijziging vast, maar push niet.

   3.2.2: Ga naar een ander filiaal (B)

   3.2.3: Verwijder die lokale branch (A) waar je de commit naar .gitattributes hebt uitgevoerd, en forceer de verwijdering zelfs als er staat dat er een commit is die niet is gepusht. Het zal die commit vergeten (het kan achteraf worden verwijderd via GC of wat dan ook, maar het is niet erg als het bestand met de fout niet enorm is)

   3.2.4: Afrekenen in filiaal A opnieuw. Het zal de vorige status van de repository downloaden zonder de vervelende bestanden en LFS-instellingen op de juiste manier in te stellen.

Dat werkt altijd!

Antwoord 16

geen van de bovenstaande commando’s werkte voor mij, ik heb hier

git status -s | cut -c 4- | xargs git update-index --assume-unchanged
rm .git/index && git reset

Antwoord 17

rennen

git add --renormalize .

en leg die wijzigingen vast. Het is veilig om te doen, zelfs wanneer een andere gebruiker hetzelfde doet op een andere branch, aangezien de LFS-aanwijzer is afgeleid van de hash van het bestand. Het kan ook enkele bestanden met verkeerde regeleindes opvangen.

Antwoord 18

Hetzelfde als @John Kugelman hierboven, maar ik heb het in een alias gezet omdat ik het een aantal keren moest doen.

   
git rm --cached -r . > /dev/null && git reset --hard > /dev/null && git rm .gitattributes > /dev/null && git reset . && git checkout . > /dev/null

Antwoord 19

Analyse

Dat komt omdat de bestanden niet worden bijgehouden door LFS, maar ze komen overeen met de beschrijving van sommige .gitattributes-bestanden.

Bijvoorbeeld

server/.gitattributes:

conf/** filter=lfs diff=lfs merge=lfs -text

• server/conf/client.conf is te groot en wordt gevolgd door LFS
• server/conf/client.gflags wordt bijgehouden in git in plaats van LFS

Client.gflags komt echter overeen met de server/.gitattributes-beschrijving, en git zal het uit LFS halen, maar het heeft geen LFS-info, en de fout zal worden gegenereerd.

Oplossing

Zoek het .gitattributes-bestand waarvan de beschrijving in het Encoutered fileterechtkwam, verwijder de verkeerde beschrijving of optimaliseer een match met jokertekens.

Optimaliseer het bovenstaande voorbeeld,
server/.gitattributes:

conf/client.conf filter=lfs diff=lfs merge=lfs -text