Etter tre måneders utvikling har det distribuerte kildekontrollsystemet Git 2.41 blitt utgitt. Git er et av de mest populære, pålitelige og høyytende versjonskontrollsystemene, og gir fleksible ikke-lineære utviklingsverktøy basert på forgrening og sammenslåing. For å sikre integriteten til historien og motstanden mot tilbakevirkende endringer, brukes implisitt hashing av hele den tidligere historien i hver forpliktelse; det er også mulig å sertifisere individuelle tagger og forpliktelser med digitale signaturer fra utviklerne.
Sammenlignet med forrige utgivelse inkluderte den nye versjonen 542 endringer, utarbeidet med deltagelse av 95 utviklere, hvorav 29 deltok i utviklingen for første gang. Hovedinnovasjoner:
- Forbedret håndtering av uoppnåelige objekter som ikke er referert i depotet (ikke referert av grener eller tagger). Uoppnåelige objekter slettes av søppelsamleren, men forblir i depotet i en viss tid før de slettes for å unngå raseforhold. For å spore perioden for forekomst av uoppnåelige objekter, er det nødvendig å feste tagger til dem med tidspunktet for endring av lignende objekter, noe som ikke tillater lagring av dem i en pakkefil der alle objekter har en felles endringstid. Tidligere ble hvert uoppnåelig objekt lagret i en egen fil, noe som førte til problemer da det var et stort antall ferske uoppnåelige objekter som ennå ikke var kvalifisert for sletting. I den nye utgivelsen brukes "cruft packs"-mekanismen som standard for å pakke uoppnåelige objekter, som lar deg lagre alle uoppnåelige objekter i en pakkefil, og data om endringstiden for hvert objekt reflekteres i en separat tabell, lagret i en fil med filtypen ".mtimes" og koblet ved hjelp av en indeksfil med filtypen ".idx".
- Opprettholde en omvendt indeks på disk for pakkefiler er aktivert som standard. Ved testing på torvalds/linux-depotet, gjorde bruken av en omvendt indeks det mulig å fremskynde ressurskrevende "git push"-operasjoner med 1.49 ganger, og enkle operasjoner som å beregne størrelsen på et enkelt objekt ved å bruke "git cat- file —batch='%(objectsize:disk)' "77 ganger. Filer (".rev") med en omvendt indeks vil bli lagret inne i depotet i ".git/objects/pack"-katalogen.
Husk at Git lagrer all data i form av objekter, som ligger i separate filer. For å øke effektiviteten ved å jobbe med depotet, plasseres objekter i tillegg i pakkefiler, der informasjon presenteres i form av en strøm av objekter som følger hverandre (et lignende format brukes når objekter overføres med git fetch og git push kommandoer). For hver pakkefil opprettes det en indeksfil (.idx), som lar deg meget raskt bestemme offset i pakkefilen som det gitte objektet er lagret ved ved hjelp av objektidentifikatoren.
Den omvendte indeksen inkludert i den nye utgivelsen er rettet mot å optimalisere prosessen med å bestemme objektidentifikatoren fra informasjon om plasseringen av objektet i pakkefilen. Tidligere ble en slik konvertering utført umiddelbart mens pakkefilen ble analysert og ble bare lagret i minnet, noe som ikke tillot lignende indekser å bli gjenbrukt og tvang indeksen til å bli generert hver gang. Operasjonen med å bygge en indeks kommer ned til å konstruere en rekke objekt-posisjonspar og sortere den etter posisjon, noe som kan ta lang tid for store pakkefiler.
For eksempel var en operasjon for å vise innholdet til objekter, som bruker en direkte indeks, 62 ganger raskere enn en operasjon for å vise størrelsen på objekter, som posisjon-til-objekt-data ikke ble indeksert for. Etter å ha brukt den omvendte indeksen, begynte disse operasjonene å ta omtrent samme tid. Omvendte indekser lar deg også fremskynde objektsendingsoperasjoner når du utfører hente- og push-kommandoer ved direkte å overføre ferdige data fra disken.
- Protokollen "legitimasjonshjelper", som brukes til å overføre legitimasjon ved tilgang til repositories med begrenset tilgang, har lagt til støtte for å sende WWW-Authenticate-hoder mellom legitimasjonsbehandleren og tjenesten der autentiseringen utføres. Støtte for WWW-Authenticate-overskriften lar deg sende OAuth-omfangsparametere for en mer detaljert separasjon av brukertilgang til repositories og avgrensning av omfangene som er tilgjengelige for forespørsler.
- Lagt til formateringsalternativet "%(ahead-behind:" til for-each-ref-kommandoen: )», som lar deg umiddelbart få informasjon om antall forpliktelser som er tilstede eller fraværende i en bestemt gren, i forhold til en annen gren (hvor mye en gren er bak eller foran en annen på forpliktelsesnivå). Tidligere, for å få slik informasjon, måtte du kjøre to separate kommandoer: «git rev-list —count main..my-feature» for å få antall forpliktelser som er unike for grenen og «git rev-list —count my-feature ..main" for å få antallet manglende commits. Nå kan slike beregninger reduseres til en enkelt kommando, noe som forenkler skrivingen av behandlere og reduserer utførelsestiden. For eksempel, for å vise grener som ikke er slått sammen og vurdere om de er bak eller foran hovedgrenen, kan du bruke en one-liner: $ git for-each-ref —no-merged=origin/HEAD \ —format ='%(refname:short) %(ahead-behind :origin/HEAD)' \refs/heads/tb/ | kolonne -t tb/cruft-extra-tips 2 96 tb/for-each-ref—ekskluder 16 96 tb/roaring-bitmaps 47 3 i stedet for det tidligere brukte skriptet, som kjører 17 ganger langsommere: $ git for-each-ref — format='%(refname:short)' —no-merged=opprinnelse/HEAD \ refs/heads/tb | mens du leser ref do ahead="$(git rev-list -count origin/HEAD..$ref)" behind="$(git rev-list -count $ref..origin/HEAD)" printf "%s %d %d\n" "$ref" "$ahead" "$behind" ferdig | kolonne -t tb/cruft-ekstra-tips 2 96 tb/for-hver-ref—ekskluder 16 96 tb/brølende bitmaps 47 3
- Alternativet "-porselen" er lagt til kommandoen "git fetch", når det er spesifisert, genereres utdata i formatet " ", mindre lesbar, men mer praktisk for parsing i skript.
- Lagt til "fetch.hideRefs"-innstillingen, som lar deg fremskynde "git fetch"-operasjoner ved å skjule noen av referansene i det lokale depotet på stadiet for å sjekke at serveren har sendt et komplett sett med objekter, noe som sparer tid ved å begrenser kontrollen kun til servere som data er direkte hentet fra. For eksempel, når du kjører en test på et system med repositories som inneholder et stort antall sporede eksterne lenker, ekskluderte alle lenker bortsett fra de som er adressert til målserveren $remote, reduserte utførelsen av git-hentingsoperasjonen fra 20 minutter til 30 sekunder. $ git -c fetch.hideRefs=refs -c fetch.hideRefs=!refs/remotes/$remote \ hente $remote
- "git fsck"-kommandoen gir muligheten til å se etter korrupsjon, kontrollsum-overholdelse og korrekthet av verdier i tilgjengelighetsbitmaps og omvendte indekser.
- Kommandoen "git clone --local" viser nå en feil når du prøver å kopiere fra et depot som inneholder symbolkoblinger inne i $GIT_DIR.
Kilde: opennet.ru