Na drie maanden ontwikkeling is het gedistribueerde bronbeheersysteem Git 2.41 uitgebracht. Git is een van de meest populaire, betrouwbare en krachtige versiebeheersystemen en biedt flexibele, niet-lineaire ontwikkeltools op basis van vertakken en samenvoegen. Om de integriteit van de geschiedenis en weerstand tegen veranderingen met terugwerkende kracht te garanderen, wordt in elke commit impliciete hashing van de gehele voorgaande geschiedenis gebruikt; het is ook mogelijk om individuele tags en commits te certificeren met digitale handtekeningen van de ontwikkelaars.
Vergeleken met de vorige release bevatte de nieuwe versie 542 wijzigingen, voorbereid met de deelname van 95 ontwikkelaars, van wie er 29 voor het eerst aan de ontwikkeling deelnamen. Belangrijkste innovaties:
- Verbeterde verwerking van onbereikbare objecten waarnaar niet wordt verwezen in de repository (waar niet naar wordt verwezen door vertakkingen of tags). Onbereikbare objecten worden verwijderd door de garbage collector, maar blijven een bepaalde tijd in de repository voordat ze worden verwijderd om race-omstandigheden te voorkomen. Om de periode van voorkomen van onbereikbare objecten bij te houden, is het noodzakelijk om er tags aan toe te voegen met de tijd van verandering van soortgelijke objecten, waardoor ze niet in één pakketbestand kunnen worden opgeslagen waarin alle objecten een gemeenschappelijke veranderingstijd hebben. Voorheen werd elk onbereikbaar object in een apart bestand opgeslagen, wat tot problemen leidde als er een groot aantal nieuwe onbereikbare objecten was die nog niet in aanmerking kwamen voor verwijdering. In de nieuwe release wordt het “cruft packs”-mechanisme standaard gebruikt voor het verpakken van onbereikbare objecten, waardoor u alle onbereikbare objecten in één pakketbestand kunt opslaan, en gegevens over het wijzigingstijdstip van elk object worden weerspiegeld in een aparte tabel, opgeslagen in een bestand met de extensie “.mtimes” en gekoppeld via een indexbestand met de extensie “.idx”.
- Het bijhouden van een omgekeerde index op schijf voor pakketbestanden is standaard ingeschakeld. Bij het testen op de torvalds/linux repository maakte het gebruik van een omgekeerde index het mogelijk om resource-intensieve “git push”-bewerkingen met 1.49 keer te versnellen, en eenvoudige bewerkingen zoals het berekenen van de grootte van een enkel object met behulp van “git cat- file —batch='%(objectgrootte:schijf)' "77 keer. Bestanden (“.rev”) met een omgekeerde index zullen worden opgeslagen in de repository in de map “.git/objects/pack”.
Bedenk dat Git alle gegevens opslaat in de vorm van objecten, die zich in afzonderlijke bestanden bevinden. Om de efficiëntie van het werken met de repository te vergroten, worden objecten bovendien in pack-bestanden geplaatst, waarin informatie wordt gepresenteerd in de vorm van een stroom van objecten die elkaar opvolgen (een soortgelijk formaat wordt gebruikt bij het overbrengen van objecten met de git fetch en git push commando's). Voor elk packbestand wordt een indexbestand (.idx) aangemaakt, waarmee u zeer snel de offset in het packbestand kunt bepalen waarin het betreffende object is opgeslagen met behulp van de objectidentifier.
De omgekeerde index in de nieuwe release is gericht op het optimaliseren van het proces van het bepalen van de object-ID op basis van informatie over de plaatsing van het object in het packbestand. Voorheen werd een dergelijke conversie direct uitgevoerd tijdens het parseren van het packbestand en werd deze alleen in het geheugen opgeslagen, waardoor vergelijkbare indexen niet opnieuw konden worden gebruikt en de index elke keer opnieuw moest worden gegenereerd. De bewerking van het bouwen van een index komt neer op het construeren van een array van object-positieparen en het sorteren ervan op positie, wat bij grote pakketbestanden lang kan duren.
Een bewerking om de inhoud van objecten weer te geven, waarbij gebruik wordt gemaakt van een directe index, was bijvoorbeeld 62 keer sneller dan een bewerking om de grootte van objecten weer te geven, waarvoor de positie-naar-object-gegevens niet waren geïndexeerd. Na gebruik van de omgekeerde index begonnen deze handelingen ongeveer even lang te duren. Met omgekeerde indexen kunt u ook het verzenden van objecten versnellen bij het uitvoeren van ophaal- en push-opdrachten door kant-en-klare gegevens rechtstreeks van schijf over te dragen.
- Het “credential helper”-protocol, dat wordt gebruikt om inloggegevens over te dragen bij toegang tot repository's met beperkte toegang, heeft ondersteuning toegevoegd voor het doorgeven van WWW-Authenticate-headers tussen de inloggegevenshandler en de service waarin authenticatie wordt uitgevoerd. Dankzij ondersteuning voor de WWW-Authenticate-header kunt u OAuth-scopeparameters doorgeven voor een gedetailleerdere scheiding van gebruikerstoegang tot repository's en een afbakening van de scopes die beschikbaar zijn voor verzoeken.
- Opmaakoptie "%(ahead-behind:" toegevoegd aan de for-each-ref-opdracht: )”, waarmee u onmiddellijk informatie kunt verkrijgen over het aantal commits dat aanwezig of afwezig is in een bepaalde branch, relatief ten opzichte van een andere branch (hoeveel de ene branch achter of voorloopt op een andere op commit-niveau). Voorheen moest je, om dergelijke informatie te verkrijgen, twee afzonderlijke commando's uitvoeren: "git rev-list —count main..my-feature" om het aantal commits te krijgen dat uniek is voor de branch en "git rev-list —count my-feature ..main” om het aantal ontbrekende commits op te halen. Nu kunnen dergelijke berekeningen worden teruggebracht tot één enkel commando, wat het schrijven van handlers vereenvoudigt en de uitvoeringstijd verkort. Om bijvoorbeeld branches weer te geven die niet zijn samengevoegd en om te evalueren of ze achter of vóór de hoofdbranch staan, kun je een oneliner gebruiken: $ git for-each-ref —no-merged=origin/HEAD \ —format ='%(refnaam:kort) %(voor-achter:origin/HEAD)' \refs/heads/tb/ | column -t tb/cruft-extra-tips 2 96 tb/for-each-ref – sluit 16 96 tb/roaring-bitmaps 47 3 uit in plaats van het eerder gebruikte script, dat 17 keer langzamer draait: $ git for-each-ref — format='%(refname:short)' —no-merged=origin/HEAD \ refs/heads/tb | while read ref do ahead="$(git rev-list -count origin/HEAD..$ref)" achter="$(git rev-list -count $ref..origin/HEAD)" printf "%s %d %d\n" "$ref" "$ahead" "$behind" klaar | kolom -t tb/cruft-extra-tips 2 96 tb/voor-elke-ref: uitsluiten 16 96 tb/roaring-bitmaps 47 3
- De “-porcelain” optie is toegevoegd aan het “git fetch” commando, indien gespecificeerd, wordt uitvoer gegenereerd in het formaat “ ", minder leesbaar, maar handiger voor parseren in scripts.
- De instelling “fetch.hideRefs” toegevoegd, waarmee je “git fetch”-bewerkingen kunt versnellen door een aantal referenties in de lokale repository te verbergen tijdens het controleren of de server een volledige set objecten heeft verzonden, wat tijd bespaart door waarbij de controle alleen wordt beperkt tot servers waarvan de gegevens rechtstreeks worden opgehaald. Wanneer je bijvoorbeeld een test uitvoert op een systeem met repositories die een groot aantal getraceerde externe links bevatten, en alle links uitsluit behalve die geadresseerd aan de doelserver $remote, werd de uitvoering van de git fetch-operatie teruggebracht van 20 minuten naar 30 seconden. $ git -c fetch.hideRefs=refs -c fetch.hideRefs=!refs/remotes/$remote \ fetch $remote
- Het commando "git fsck" biedt de mogelijkheid om te controleren op corruptie, naleving van de controlesom en juistheid van waarden in toegankelijkheidsbitmaps en omgekeerde indexen.
- Het "git clone --local" commando geeft nu een foutmelding weer bij een poging om te kopiëren vanuit een repository die symbolische links bevat binnen $GIT_DIR.
Bron: opennet.ru