Git 2.39 source control release

Na twee maanden ontwikkeling is het gedistribueerde bronbeheersysteem Git 2.39 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 483 wijzigingen, voorbereid met de medewerking van 86 ontwikkelaars, van wie er 31 voor het eerst aan de ontwikkeling deelnamen. Belangrijkste innovaties:

  • Het “git shortlog” commando, ontworpen om samenvattingen weer te geven met statistieken uit de geschiedenis van wijzigingen, heeft een “-group” optie toegevoegd voor het willekeurig groeperen van commits op velden, niet beperkt tot auteur of committer. Om bijvoorbeeld een lijst met ontwikkelaars weer te geven met informatie over het aantal wijzigingen, rekening houdend met de helpers genoemd in het veld "Co-authored-by", zou je het commando kunnen gebruiken: git shortlog -ns --group=author - -group=trailer:co-auteur-door

    Shortlog-uitvoer kan worden geaggregeerd met behulp van opmaakspecificaties, en de “--group”-optie kan het maken van complexe rapporten aanzienlijk vereenvoudigen en de noodzaak voor extra sorteeropdrachten elimineren. Om bijvoorbeeld een rapport te maken met informatie over hoeveel commits voor een bepaalde release elke maand zijn geaccepteerd, kun je het volgende specificeren: git shortlog v2.38.0.. —date='format:%Y-%m' —group=' %cd' -s 2 2022-08 47 2022-09 405 2022-10 194 2022-11 5 2022-12 Voorheen zou het nodig zijn geweest om de sort- en uniq-hulpprogramma's te gebruiken om een ​​soortgelijke bewerking uit te voeren: git log v2.38.0 .. —date='format:%Y -%m' —format='%cd' | sorteer | uniq-c

  • De mogelijkheden van het “cruft packs”-mechanisme, ontworpen voor het verpakken van onbereikbare objecten waarnaar niet wordt verwezen in de repository (waar niet naar wordt verwezen door vertakkingen of tags), zijn uitgebreid. 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. Met het “cruft packs”-mechanisme kunt u alle onbereikbare objecten in één pakketbestand opslaan en gegevens over het wijzigingstijdstip van elk object in een aparte tabel weergeven, opgeslagen in een apart bestand met de extensie “.mtimes”, zodat ze dat niet doen mogen niet overlappen met de totale wijzigingstijd.

    De tijdsduur dat onbereikbare objecten in de repository blijven voordat ze daadwerkelijk worden verwijderd, wordt bepaald door de optie “—prune=” " Hoewel het uitstellen van het verwijderen een redelijk effectieve en praktische manier is om corruptie van de repository als gevolg van raceomstandigheden te voorkomen, is het niet 100% betrouwbaar. Om het gemakkelijker te maken een beschadigde repository te herstellen, biedt de nieuwe release de mogelijkheid om ontbrekende objecten op te slaan door de “--expire-to” optie toe te voegen aan het “git repack” commando, waarmee je een bestand kunt specificeren om een ​​extern bestand te maken kopie van alle verwijderde objecten. Om bijvoorbeeld onbereikbare objecten die de afgelopen 5 minuten niet zijn gewijzigd in het backup.git bestand op te slaan, kun je het commando gebruiken: git repack --cruft --cruft-expiration=5.minutes.ago -d --expire -to=../back-up.git

  • Aanzienlijk verhoogde (tot 70%) de snelheid van de "git grep -cached" bewerking bij het zoeken in gebieden die gedeeltelijk klonen gebruiken (sparse-checkout) en waarvoor er gedeeltelijke indexen zijn (sparse index). Voorheen werd bij het specificeren van de optie "-cached" de zoekopdracht eerst in de reguliere index uitgevoerd en vervolgens in de gedeeltelijke index, wat leidde tot merkbare vertragingen bij het zoeken in grote repository's.
  • De verificatie door de server van de samenhang van nieuwe objecten voordat ze in de repository worden geplaatst tijdens de "git push" -bewerking is versneld. Door bij het controleren over te schakelen op het alleen rekening houden met gedeclareerde links, in een testrepository met 7 miljoen links, waarvan slechts 3% wordt gedekt door de push-operatie, konden de gemaakte optimalisaties de controletijd met 4.5 keer verkorten.
  • Om te beschermen tegen potentiële overflows van gehele getallen in de code, beperkt het commando "git apply" de maximale grootte van patches die kunnen worden verwerkt. Als de patch groter is dan 1 GB, wordt er nu een foutmelding weergegeven.
  • Ter bescherming tegen potentiële kwetsbaarheden zijn er wijzigingen aangebracht om onnodige informatie op te ruimen uit de headers die zijn ingesteld bij gebruik van de h2h3-module met de optie GIT_TRACE_CURL=1 of GIT_CURL_VERBOSE=1 samen met HTTP/2.
  • Bij het uitvoeren van een check-out op een branch die een symbolische link naar een andere branch is, geeft het "git symbolic-ref HEAD" commando nu de naam van de doelbranch weer in plaats van de naam van de symlink.
  • Ondersteuning toegevoegd voor het @{-1} argument aan de “--edit-description” optie (“git branch —edit-description @{-1}”) voor het bewerken van de beschrijving van een voorgaande branch.
  • Het "git merge-tree --stdin" commando toegevoegd om een ​​lijst met opties door te geven via standaardinvoer.
  • Op netwerkbestandssystemen is de fsmonitor-handler, die veranderingen in het bestandssysteem controleert, standaard uitgeschakeld.

Bron: opennet.ru

Voeg een reactie