Du tog verkligen bort alla varianter av ett filnamn om en blob flyttades under sin livstid. git log --name-only --follow --all -- filename kan hjälpa dig att hitta namnbyten.

Du filtrerade verkligen alla referenser: använd --tag-name-filter cat -- --all när du anropar git-filter-branch.

Klona den med git clone file:///sökväg/till/kodförråd. Klonen kommer inte att ha de borttagna objekten. Se git-clone[1]. (Observera att kloning med en vanlig sökväg bara hårdlänkar allt!)

Ta bort de ursprungliga referenserna som säkerhetskopieras av git-filter-branch: säg git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d.

Låt alla referensloggar upphöra med git reflog expire --expire=now --all.

Skräpsamla alla orefererade objekt med git gc --prune=now (eller om din git-gc inte är tillräckligt ny för att stödja argument till --prune, använd git repack -ad; git prune i stället).

Vid redigering av filer kontrollerar git-filter-branch avsiktligt varje incheckning som den fanns i det ursprungliga kodförrådet. Om ett kodförråd har 10^5 filer och 10^5 incheckningar, men varje incheckning bara modifierar fem filer, kommer git-filter-branch att kräva 10^10 modifieringar, trots att det bara finns (högst) 5*10^5 unika blobbar.

Om du försöker fuska och försöker få git-filter-branch att bara fungera på filer som modifierats i en incheckning, så händer två saker

Även om det inte finns behov av att redigera filer utan bara att t.ex. byta namn på eller ta bort några och därmed undvika att checka ut varje fil (dvs. --index-filter kan användas), skickas fortfarande skalkodsnuttar för filtren. Det betyder att det för varje incheckning måste finnas ett förberett Git-kodförråd där filtren kan köras. Det är en omfattande förberedelse.

Dessutom, skapas eller uppdateras flera ytterligare filer per incheckning av git-filter-branch. Några av dessa är till för att stödja de bekvämlighetsfunktioner som tillhandahålls av git-filter-branch (som map()), medan andra är till för att hålla reda på internt tillstånd (men kunde också ha nåts av användarfilter; ett av git-filter-branchs regressionstester gör det). Detta innebär i huvudsak att man använder filsystemet som en IPC-mekanism mellan git-filter-branch och de användardefinierade filtren. Diskar tenderar att vara en långsam IPC-mekanism, och att skriva dessa filer representerar också effektivt en påtvingad synkroniseringspunkt mellan separata processer som vi träffar vid varje incheckning.

De användardefinierade skal-kommandona kommer sannolikt att involvera en pipeline av kommandon, vilket resulterar i att många processer per incheckning skapas. Att skapa och köra en annan process tar en mycket varierande tid mellan operativsystem, men på alla plattformar är det mycket långsamt i förhållande till att anropa en funktion.

Själva git-filter-branch är skrivet i skal (sh), vilket är ganska långsamt. Detta är det enda prestandaproblemet som skulle kunna åtgärdas bakåtkompatibelt, men jämfört med ovanstående problem som är inneboende i designen av git-filter-branch, är själva verktygets språk ett relativt litet problem.

Någon kan ha en uppsättning "fungerande och testade filter" som de dokumenterar eller tillhandahåller till en kollega, som sedan kör dem på ett annat operativsystem där samma kommandon inte fungerar/testas (några exempel på git-filter-branch manualsidan påverkas också av detta). Skillnader mellan BSD och GNU-användarland kan verkligen bita. Med tur dyker felmeddelanden upp. Men lika troligt är det att kommandona antingen inte utför den filtrering som begärs, eller så korrumperar de tyst genom att göra någon oönskad ändring. Den oönskade ändringen kan bara påverka ett fåtal incheckningar, så det är inte nödvändigtvis uppenbart heller. (Det faktum att problem inte nödvändigtvis är uppenbara innebär att de sannolikt kommer att gå obemärkta förbi förrän den omskrivna historiken har använts ett bra tag, och då är det verkligen svårt att rättfärdiga ytterligare en flaggdag för ytterligare en omskrivning.)

Filnamn med mellanslag hanteras ofta fel av shell-kodavsnitt eftersom de orsakar problem för shell-pipelines. Inte alla är bekanta med find -print0, xargs -0, git-ls-files -z, etc. Även personer som är bekanta med dem kan anta att sådana flaggor inte är relevanta eftersom någon annan döpte om sådana filer i sitt kodförråd innan personen som utförde filtreringen gick med i projektet. Och ofta kanske inte ens de som är bekanta med att hantera argument med mellanslag gör det bara för att de inte är i tankesättet att tänka på allt som kan gå fel.

Filnamn som inte är ascii kan tas bort i tysthet trots att de finns i en önskad katalog. Att bara behålla önskade sökvägar görs ofta med hjälp av pipelines som git ls-files | grep -v ^WANTED_DIR/ | xargs git rm. ls-files citerar bara filnamn om det behövs, så folk kanske inte märker att en av filerna inte matchade regex (åtminstone inte förrän det är alldeles för sent). Ja, någon som känner till core.quotePath kan undvika detta (såvida de inte har andra specialtecken som \t, \n eller "), och personer som använder ls-files -z med något annat än grep kan undvika detta, men det betyder inte att de kommer att göra det.

På liknande sätt, när man flyttar filer, kan man upptäcka att filnamn med tecken som icke-ascii eller specialtecken hamnar i en annan katalog, en som innehåller ett dubbelt citattecken. (Detta är tekniskt sett samma problem som ovan med citattecken, men kanske ett intressant annorlunda sätt som det kan och har manifesterats som ett problem.)

Det är alldeles för lätt att av misstag blanda ihop gammal och ny historik. Det är fortfarande möjligt med vilket verktyg som helst, men git-filter-branch inbjuder nästan till det. Om man har tur är den enda nackdelen att användarna blir frustrerade över att de inte vet hur de ska krympa sitt kodförråd och ta bort det gamla. Om de har otur slår de ihop gammal och ny historik och får flera "kopior" av varje incheckning, av vilka vissa innehåller oönskade eller känsliga filer och andra inte. Detta sker på flera olika sätt:

Annoterade taggar kan av misstag konverteras till lättviktstaggar på grund av ett av två problem:

Alla incheckningsmeddelanden som anger en kodning kommer att bli korrupta av omskrivningen; git-filter-branch ignorerar kodningen, tar de ursprungliga bytena och matar den till commit-tree utan att ange rätt kodning. (Detta händer oavsett om --msg-filter används eller inte.)

Incheckningsmeddelanden (även om de alla är i UTF-8) blir som standard korrupta på grund av att de inte uppdateras — alla referenser till andra incheckningshashar i incheckningsmeddelanden kommer nu att referera till incheckningar som inte längre finns.

Det finns inga funktioner som hjälper användare att hitta vilket oönskat skräp de ska ta bort, vilket innebär att de är mycket mer benägna att ha ofullständiga eller partiella rensningar som ibland leder till förvirring och att folk slösar tid på att försöka förstå. (Till exempel tenderar folk att bara leta efter stora filer att ta bort i stället för stora kataloger eller tillägg, och när de väl gör det, kommer personer som använder det nya kodförrådet och går igenom historiken någon gång senare att märka en katalog för bygg-artefakter som innehåller vissa filer men inte andra, eller en cache av beroenden (node_modules eller liknande) som aldrig kunde ha fungerat eftersom den saknar vissa filer.)

Om --prune-empty inte anges kan filtreringsprocessen skapa massor av förvirrande tomma incheckningar

Om --prune-empty anges, så beskärs även avsiktligt placerade tomma incheckningar från tiden före filtreringsåtgärden, i stället för att bara beskära incheckningar som blev tomma på grund av filtreringsregler.

Om --prune-empty anges, missas ibland tomma incheckningar och lämnas kvar ändå (ett något ovanligt programfel, men det händer…​)

Ett mindre problem, men användare som har som mål att uppdatera alla namn och e-postadresser i ett förar kan ledas till --env-filter som bara uppdaterar författare och incheckare, och saknar taggare.

Om användaren anger ett --tag-name-filter som mappar flera taggar till samma namn, visas ingen varning eller fel; git-filter-branch skriver helt enkelt över varje tagg i någon odokumenterad fördefinierad ordning vilket resulterar i endast en tagg i slutet. (Ett regressionstest av git-filter-branch kräver detta överraskande beteende.)

Att komma på rätt shell-kodsavsnitt för att utföra den filtrering man vill ha är ibland svårt om man inte bara gör en trivial modifiering, som att ta bort ett par filer. Tyvärr lär sig folk ofta om kodavsnittet är rätt eller fel genom att prova sig fram, men om det är rätt eller fel kan variera beroende på speciella omständigheter (mellanslag i filnamn, non-ascii filnamn, roliga författarnamn eller e-postadresser, ogiltiga tidszoner, förekomst av grafts eller ersättningsobjekt, etc.), vilket innebär att de kan behöva vänta länge, stöta på ett fel och sedan starta om. Prestandan för git-filter-branch är så dålig att denna cykel är smärtsam, vilket minskar tiden som finns tillgänglig för att noggrant kontrollera om (för att inte tala om vad det gör med tålamodet hos den person som gör omskrivningen även om de tekniskt sett har mer tid tillgänglig). Detta problem förvärras ytterligare eftersom fel från trasiga filter kanske inte visas på länge och/eller går vilse i ett hav av utdata. Ännu värre är att trasiga filter ofta bara resulterar i tysta felaktiga omskrivningar.

Som grädde på moset, även när användare äntligen hittar fungerande kommandon, vill de naturligtvis dela med sig av dem. Men de kanske inte är medvetna om att deras kodförråd inte hade vissa specialfall som någon annans har. Så när någon annan med ett annat kodförråd kör samma kommandon, drabbas de av problemen ovan. Eller så kör användaren bara kommandon som egentligen granskades för specialfall, men de kör dem på ett annat operativsystem där det inte fungerar, som nämnts ovan.