GitHub ndryshoi mënyrën se si gjeneron arkivat e gjeneruara automatikisht ".tar.gz" dhe ".tgz" në faqet e lëshimit, gjë që çoi në ndryshime në shumat e tyre të kontrollit dhe dështime masive në sistemet e automatizuara të ndërtimit që kontrollojnë arkivat e shkarkuar nga GitHub kundrejt atyre të mëparshme për të konfirmuar integritetin shumat kontrolluese të ruajtura, për shembull, të vendosura në meta të dhënat e paketave ose në skriptet e ndërtimit.
Duke filluar me versionin 2.38, paketa e veglave Git përfshinte si parazgjedhje një implementim të integruar të gzip, i cili bëri të mundur unifikimin e mbështetjes për këtë metodë kompresimi në sistemet operative dhe përmirësimin e performancës së krijimit të arkivit. GitHub zgjodhi ndryshimin pas përditësimit të versionit të git në infrastrukturën e tij. Problemi u shkaktua nga fakti se arkivat e kompresuara të krijuara nga implementimi i integruar i gzip-it të bazuar në zlib janë binare të ndryshëm nga arkivat e krijuar nga programi gzip, gjë që rezultoi në kontrolle të ndryshme për arkivat e krijuar nga versione të ndryshme të git gjatë ekzekutimit. komanda "git archive".
Prandaj, pas përditësimit të git në GitHub, në faqet e lëshimit filluan të shfaqen arkiva paksa të ndryshme, të cilat nuk e kaluan verifikimin duke përdorur kontrollet e vjetra. Problemi u shfaq në sisteme të ndryshme ndërtimi, sisteme të integruara të vazhdueshme dhe mjete për ndërtimin e paketave nga kodi burimor. Për shembull, montimi i rreth 5800 porteve FreeBSD, kodet burimore për të cilat u shkarkuan nga GitHub, u prish.
Në përgjigje të ankesave fillestare për defektet, GitHub fillimisht citoi faktin se shumat e kontrollit të përhershëm për arkivat nuk ishin kurrë të garantuara. Pasi u tregua se do të kërkohej një punë e madhe për përditësimin e meta të dhënave në ekosisteme të ndryshme për të rivendosur funksionalitetin e sistemeve të ndërtuara të prekura, përfaqësuesit e GitHub ndryshuan mendjen, rikthyen ndryshimin dhe kthyen metodën e vjetër të gjenerimit të arkivave.
Zhvilluesit e Git nuk kanë marrë ende një vendim dhe po diskutojnë vetëm veprimet e mundshme. Opsionet e konsideruara përfshinin kthimin në përdorimin e programit të paracaktuar të gzip; shtimi i flamurit "--stabil" për të ruajtur përputhshmërinë me arkivat e vjetra; lidhja e zbatimit të integruar me një format të veçantë arkivi; përdorimi i programit gzip për kryerjet e vjetra dhe zbatimi inline për kryerjet duke filluar nga një datë e caktuar; garantimi i qëndrueshmërisë së formatit vetëm për arkivat e pakompresuara.
Vështirësia e marrjes së një vendimi shpjegohet me faktin se rikthimi në një thirrje në një shërbim të jashtëm nuk e zgjidh plotësisht problemin e pandryshueshmërisë së shumës së kontrollit, pasi një ndryshim në programin e jashtëm gzip mund të çojë gjithashtu në një ndryshim në formatin e arkivit. Aktualisht, një grup arnimesh është propozuar për rishikim që kthen sjelljen e vjetër si parazgjedhje (duke thirrur një mjet të jashtëm gzip) dhe përdor zbatimin e integruar në mungesë të një mjeti gzip në sistem. Arnimet gjithashtu i shtojnë dokumentacionit një përmendje se stabiliteti i daljes "git archive" nuk është i garantuar dhe formati mund të ndryshojë në të ardhmen.
Burimi: opennet.ru