Further proofread chapter 9

Author: petk

book/01-introduction/sections/what-is-git.asc

@@ -94,7 +94,7 @@ Te datoteke so povlečene iz stisnjene podatkovne baze v direktoriju Git in dane
 Področje priprave je datoteka, v splošnem vsebovana v vašem direktoriju Git, ki shranjuje informacije o tem, kaj bo šlo v vašo naslednjo potrditev.
 Njegovo tehnično ime v jeziku Git je »indeks« (angl. _index_), vendar se pogosto imenuje tudi področje priprave podatkov (angl. _staging area_).
 
-Direktorij Git je, kjer Git shranjuje meta podatke in objektno podatkovno bazo za vaš projekt.
+Direktorij Git je, kjer Git shranjuje metapodatke in objektno podatkovno bazo za vaš projekt.
 To je najpomembnejši del Gita in je, kar se kopira, ko _klonirate_ repozitorij iz drugega računalnika.
 
 Osnovni potek dela Git gre nekako takole:

book/03-git-branching/sections/nutshell.asc

@@ -18,9 +18,9 @@ $ git commit -m 'Initial commit'
 ----
 
 Ko ustvarite potrditev s pogonom `git commit`, Git preveri kontrolne vsote za vsak poddirektorij (v tem primeru samo vrhnji direktorij projekta) in jih shrani kot drevesni objekt v repozitorij Git.
-Git nato ustvari objekt potrditve, ki ima meta podatke in kazalec na vrhnje drevo projekta, da lahko ponovno ustvari posnetek, ko je treba.(((Ukazi Git, commit)))
+Git nato ustvari objekt potrditve, ki ima metapodatke in kazalec na vrhnje drevo projekta, da lahko ponovno ustvari posnetek, ko je treba.(((Ukazi Git, commit)))
 
-Vaš repozitorij Git sedaj vsebuje pet objektov: tri _blobe_ (vsak predstavlja vsebino ene izmed treh datotek), eno _drevo_, ki izpisuje vsebino direktorija in določa, katera imena datotek so shranjena kot blobi, in eno _potrditev_ s kazalcem na to vrhnje drevo ter vse meta podatke potrditve.
+Vaš repozitorij Git sedaj vsebuje pet objektov: tri _blobe_ (vsak predstavlja vsebino ene izmed treh datotek), eno _drevo_, ki izpisuje vsebino direktorija in določa, katera imena datotek so shranjena kot blobi, in eno _potrditev_ s kazalcem na to vrhnje drevo ter vse metapodatke potrditve.
 
 .Potrditev in njeno drevo
 image::images/commit-and-tree.png[Potrditev in njeno drevo]

book/09-git-and-other-scms/sections/client-hg.asc

@@ -62,7 +62,7 @@ $ git log --oneline --graph --decorate
 ----
 
 Opazili boste, da delo z Mercurialovim repozitorijem uporablja standardni ukaz `git clone`.
-To je zato, ker git-remote-hg deluje na precej nizki ravni, uporabljajoč podoben mehanizem, kot je implementacija Gitovega protokola HTTP/S (oddaljeni pomočniki).
+To je zato, ker git-remote-hg deluje na precej nizki ravni in uporablja podoben mehanizem, kot je implementacija Gitovega protokola HTTP/S (oddaljeni pomočniki).
 Ker sta Git in Mercurial zasnovana tako, da ima vsak odjemalec polno kopijo zgodovine repozitorija, ta ukaz naredi celotno kopijo, vključno z vso zgodovino projekta, in to relativno hitro.
 
 Ukaz `log` prikaže dve spremembi, najnovejša od teh je označena z velikim številom referenc.

book/09-git-and-other-scms/sections/client-p4.asc

@@ -17,7 +17,7 @@ Druga možnost pa je git-p4, most na strani odjemalca, ki vam omogoča uporabo G
 (((Perforce, Git Fusion)))
 Perforce zagotavlja izdelek, imenovan Git Fusion (dostopen na https://www.perforce.com/git-fusion[^]), ki sinhronizira strežnik Perforce z repozitoriji Git na strežniški strani.
 
-====== Setting Up
+====== Nastavitev
 
 Za svoje primere bomo uporabili najlažjo namestitveno metodo Git Fusion in sicer prenos virtualne naprave, ki poganja prikriti proces Perforce in Git Fusion.
 Sliko virtualne naprave lahko dobite na https://www.perforce.com/downloads/Perforce/20-User[^] in ko se prenos konča, ga uvozite v svoj najljubši program za virtualizacijo (uporabili bomo VirtualBox).
@@ -146,7 +146,7 @@ view = //depot/Talkhouse/main-dev/... ...
 
 To je preslikava med vejami Perforce in vejami Git.
 Odsek se lahko imenuje poljubno, dokler je ime edinstveno.
-`git-branch-name` omogoča pretvorbo depot poti, ki bi bil pod Gitom neroden, v bolj prijazno ime.
+`git-branch-name` omogoča pretvorbo poti depoja (angl. _depot_) v bolj prijazno ime, saj bi bilo pod Gitom nerodno.
 Nastavitev `view` nadzoruje, kako so datoteke iz Perforce preslikane v repozitorij Git, pri čemer se uporablja standardna sintaksa preslikave pogledov.
 Določite lahko več preslikav kot v tem primeru:
 
@@ -161,7 +161,7 @@ view = //depot/project1/main/... project1/...
 Tako lahko, če običajna preslikava delovnega prostora vključuje spremembe v strukturi map, to replicirate z repozitorijem Git.
 
 Zadnja datoteka, o kateri bomo razpravljali, je `users/p4gf_usermap`, ki preslika uporabnike Perforce v uporabnike Git, in ki je morda sploh ne boste potrebovali.
-Pri pretvorbi iz nabora sprememb Perforce v potrditev Git, je privzeto obnašanje Git Fusiona, da poišče uporabnika Perforce in uporabi tam shranjen e-poštni naslov in polno ime za polje avtorja/izvajalca v Gitu.
+Pri pretvorbi iz nabora sprememb Perforce v potrditev Git, je privzeto obnašanje Git Fusiona, da poišče uporabnika Perforce in uporabi tam shranjen e-poštni naslov in polno ime za polje avtorja/potrjevalca v Gitu.
 Pri pretvorbi v drugo smer pa privzeto poišče uporabnika Perforce z e-poštnim naslovom, shranjenim v polju avtorja potrditve Git, in pošlje nabor sprememb kot tega uporabnika (s primernimi dovoljenji).
 V večini primerov bo ta način obnašanja povsem dovolj, vendar upoštevajte naslednjo preslikovalno datoteko:
 
@@ -286,12 +286,12 @@ To https://10.0.1.254/Jam
 ----
 
 Git misli, da je to delovalo.
-Poglejmo zgodovino datoteke `README` iz zornega kota Perfocea z uporabo lastnosti revizijskega grafa `p4v`:
+Poglejmo zgodovino datoteke `README` iz zornega kota Perforca z uporabo lastnosti revizijskega grafa `p4v`:
 
 .Revizijski graf Perforce, ki izhaja iz potiskanja Git
 image::images/git-fusion-perforce-graph.png["Revizijski graf Perforce, ki izhaja iz potiskanja Git"]
 
-Če tega pogleda še niste videli, se vam lahko zdi zmedeno, toda prikazuje iste zasnove kot grafični prikazovalnik zgodovine Gita.
+Če tega pogleda še niste videli, se vam lahko zdi zmeden, toda prikazuje iste zasnove kot grafični prikazovalnik zgodovine Gita.
 Gledamo zgodovino datoteke `README`, zato nam drevesna struktura v zgornjem levem kotu prikazuje samo to datoteko, ki se pojavlja v različnih vejah.
 Na zgornjem desnem delu imamo vizualni graf, kako so povezane različne različice datoteke, in celostni pogled na ta graf je na spodnjem desnem delu.
 Preostanek prikaza je namenjen podrobnostim za izbrano revizijo (v tem primeru `2`).
@@ -300,7 +300,7 @@ Ena stvar, ki jo je treba opaziti, je, da se graf zdi povsem enak kot v Gitovi z
 Perforce ni imel imenovane veje, kjer bi shranil potrditvi `1` in `2`, zato je ustvaril vejo »anonymous« v imeniku `.git-fusion`.
 To se bo zgodilo tudi za imenovane veje Git, ki se ne ujemajo z imenovano vejo Perforce (kasneje pa jih lahko preslikate na vejo Perforce z uporabo konfiguracijske datoteke).
 
-Večina tega se zgodi za zavesami, vendar končni rezultat je, da lahko ena oseba v ekipi uporablja Git, druga pa lahko Perfoce in nobena izmed njiju bo vedela o izbiri drug drugega.
+Večina tega se zgodi za zavesami, vendar končni rezultat je, da lahko ena oseba v ekipi uporablja Git, druga pa lahko Perforce in nobena izmed njiju bo vedela o izbiri drug drugega.
 
 ====== Povzetek Git-Fusion
 
@@ -318,11 +318,11 @@ Lahko celo uporabite podmodule Git (čeprav bodo za uporabnike Perforce videti 
 (((Ukazi Git, p4)))
 Git-p4 je most med Gitom in Perforceom v dveh smereh.
 Deluje v celoti znotraj vašega repozitorija Git, zato ne boste potrebovali nobene vrste dostopa do strežnika Perforce (razen seveda uporabniških poverilnic).
-Git-p4 ni tako prilagodljiva ali popolna rešitev kot Git Fusion, vendar vam omogoča, da večino tega, kar bi radi storili, izvedete brez poseganja v okolje strežnika.
+Git-p4 ni tako prilagodljiva ali popolna rešitev tako kot Git Fusion, vendar vam omogoča, da večino tega, kar bi radi storili, izvedete brez poseganja v okolje strežnika.
 
 [NOTE]
 ======
-Potrebovali boste orodje `p4` nekje v vaši poti `PATH`, da boste lahko delali z git-p4.
+Da boste lahko delali z git-p4, boste potrebovali orodje `p4` nekje v vaši poti `PATH`.
 V času tega pisanja je prosto dostopno na https://www.perforce.com/downloads/Perforce/20-User[^].
 ======
 
@@ -350,7 +350,7 @@ Initialized empty Git repository in /private/tmp/www-shallow/.git/
 Doing initial import of //depot/www/live/ from revision #head into refs/remotes/p4/master
 ----
 
-To ustvari »površinski« klon v izrazoslovju Git; uvozimo samo najnovejšo revizijo Perforce v Git; spomnimo se, da Perforce ni zasnovan tako, da bi vsakemu uporabniku zagotovil vsako revizijo.
+To ustvari »površinski« (angl. _shallow_) klon v izrazoslovju Git; v Git uvozimo samo najnovejšo revizijo Perforce; spomnimo se, da Perforce ni zasnovan tako, da bi vsakemu uporabniku zagotovil vsako revizijo.
 To je dovolj za uporabo Gita kot odjemalca Perforce, vendar za druge namene ni dovolj.
 
 Ko je postopek končan, imamo popolnoma funkcionalni repozitorij Git:
@@ -406,8 +406,8 @@ $ git log --oneline --all --graph --decorate
 ----
 
 Videti je, da sta se različna razvoja `master` in `p4/master` razšla.
-Perforceov sistem razvejanja ni _nič_ podoben Gitovemu, zato oddaja potrditev združitev nima smisla.
-Git-p4 priporoča, da pred oddajo ponovno bazirate svoje potrditve, za to pa ima celo pripravljeno bližnjico:
+Perforceov sistem razvejanja ni _nič_ podoben Gitovemu, zato predložitev potrditev združitev nima smisla.
+Git-p4 priporoča, da pred predložitvijo ponovno bazirate svoje potrditve, za to pa ima celo pripravljeno bližnjico:
 
 [source,console]
 ----
@@ -523,7 +523,7 @@ $ git log --oneline --all --graph --decorate
 Rezultat je tak, kot da bi pravkar izvedli `git push`, kar je najbližja analogija temu, kar se je dejansko zgodilo.
 
 Upoštevajte, da se med tem postopkom vsaka potrditev Git pretvori v nabor sprememb Perforce; če jih želite stisniti v en sam nabor sprememb, to lahko storite s pomočjo interaktivnega zaslona ponovnega baziranja pred zagonom `git p4 submit`.
-Poleg tega bodite pozorni na to, da se zgoščene vrednosti SHA-1 vseh potrditev, ki so bile oddane kot nabori sprememb, spremenijo; to je zato, ker git-p4 dodaja vrstico na konec vsake pretvorjene potrditve:
+Poleg tega bodite pozorni na to, da se zgoščene vrednosti SHA-1 vseh potrditev, ki so bile predložene kot nabori sprememb, spremenijo; to je zato, ker git-p4 dodaja vrstico na konec vsake pretvorjene potrditve:
 
 [source,console?prompt=$]
 ----
@@ -558,8 +558,8 @@ $ git log --oneline --all --graph --decorate
 ----
 
 Zgodovina Git in Perforce se začneta razhajati po potrditvi `775a46f`.
-Na Git strani imamo dve potrditvi, nato potrditev združitve z glavo Perforca in še eno potrditev.
-Poskusimo jih zdaj predložiti na stran Perforce na vrh enega samega nabora spremembe.
+Na Gitovi strani imamo dve potrditvi, nato potrditev združitve z glavo Perforca in še eno potrditev.
+Poskusimo jih zdaj predložiti (angl. _submit_) na stran Perforce na vrh enega samega nabora spremembe.
 Poglejmo, kaj bi se zgodilo, če bi poskusili predložiti zdaj:
 
 [source,console]
@@ -573,7 +573,7 @@ Would apply
   3be6fd8 Correct email address
 ----
 
-Zastavica `-n` je kratka oblika za `--dry-run`, ki poskusi poročati, kaj bi se zgodilo, če bi ukaz za oddajo dejansko tekel.
+Zastavica `-n` je kratka oblika za `--dry-run`, ki poskusi poročati, kaj bi se zgodilo, če bi ukaz za predložitev dejansko tekel.
 V tem primeru se zdi, da bi ustvarili tri spremembe Perforce, ki se ujemajo s tremi potrditvami nezdružitev, ki še ne obstajajo na strežniku Perforce.
 To se zdi točno tisto, kar želimo, torej poglejmo, kako se izkaže:
 
@@ -592,15 +592,15 @@ $ git log --oneline --all --graph --decorate
 * 70eaf78 Initial import of //depot/www/live/ from the state at revision #head
 ----
 
-Naša zgodovina je postala linearna, tako kot bi bilo po ponovnem baziranju pred oddajo (kar je dejansko tudi res).
+Naša zgodovina je postala linearna, tako kot bi bilo po ponovnem baziranju pred predložitvijo (kar je dejansko tudi res).
 To pomeni, da lahko ustvarjate, delate, zavržete in združujete veje na strani Git, ne da bi se bali, da bo vaša zgodovina na kakršenkoli način postala nezdružljiva s Perforceom.
 Če lahko ponovno bazirate, lahko prispevate k strežniku Perforce.
 
 [[_git_p4_branches]]
 ====== Veje
 
-Če ima vaš projekt v Perforcu več vej, še niste obupali; git-p4 lahko to obdela na način, ki se zdi kot Git.
-Recimo, da je vaš depo Perforce urejen takole:
+Če ima vaš projekt v Perforcu več vej, imate srečo; git-p4 lahko to obdela na način, ki se zdi kot Git.
+Recimo, da je vaš depo (angl. _depot_) Perforce urejen takole:
 
 [source]
 ----
@@ -638,7 +638,7 @@ $ cd project; git log --oneline --all --graph --decorate
 * 2b83451 Project init
 ----
 
-Opazite »@all« določevalec v poti depoja; to pove git-p4, naj ne klonira samo najnovejšega nabora sprememb za to poddrevo, temveč celoten nabor sprememb, ki so se kdaj koli dotaknile teh poti.
+Opazite določevalec »@all« v poti depoja; to pove git-p4, naj ne klonira samo najnovejšega nabora sprememb za to poddrevo, temveč celoten nabor sprememb, ki so se kdaj koli dotaknile teh poti.
 To je bližje zasnovi kloniranja v Gitu, vendar lahko pri delu na projektu z dolgo zgodovino to traja nekaj časa.
 
 Zastavica `--detect-branches` pove git-p4, naj uporabi specifikacije vej Perforce za preslikavo vej na reference Git.
@@ -656,16 +656,16 @@ $ git clone --detect-branches //depot/project@all .
 Nastavljanje konfiguracijske spremenljivke `git-p4.branchList` na `main:dev` pove git-p4, da sta `main` in `dev` obe veji in da je druga veja potomec prve.
 
 Če zdaj naredimo `git checkout -b dev p4/project/dev` in naredimo nekaj potrditev, bo git-p4 dovolj pameten, da bo pravilno ciljal na pravo vejo, ko bomo izvedli `git p4 submit`.
-Na žalost git-p4 ne more mešati plitvih klonov in več vej; če imate ogromen projekt in želite delati na več kot eni veji, boste morali `git p4 clone` izvesti enkrat za vsako vejo, v katero želite oddati.
+Na žalost git-p4 ne more mešati površinskih klonov in več vej; če imate ogromen projekt in želite delati na več kot eni veji, boste morali `git p4 clone` izvesti enkrat za vsako vejo, v katero želite predložiti.
 
 Za ustvarjanje ali integracijo vej boste morali uporabiti odjemalca Perforce.
-Git-p4 lahko samo sinhronizira in odda obstoječe veje in to lahko stori samo po eno linearno spremembo hkrati.
-Če združite dve veji v Git in poskušate oddati novo zbirko sprememb, bo zabeleženo samo nekaj sprememb datotek; izgubljeni bodo metapodatki o tem, katere veje so vključene v integracijo.
+Git-p4 lahko samo sinhronizira in predloži obstoječe veje in to lahko stori samo po eno linearno spremembo hkrati.
+Če združite dve veji v Git in poskušate predložiti novo zbirko sprememb, bo zabeleženo samo nekaj sprememb datotek; izgubljeni bodo metapodatki o tem, katere veje so vključene v integracijo.
 
 ===== Povzetek Gita in Perforca
 
-Git-p4 omogoča uporabo poteka dela Git s strežnikom Perforce in je zelo učinkovit pri tem.
+Git-p4 omogoča uporabo poteka dela Git s strežnikom Perforce in je pri tem zelo učinkovit.
 Vendar pa je pomembno vedeti, da je Perforce odgovoren za vir in da uporabljate Git le lokalno.
-Bodite previdni pri deljenju potrditev Git; če imate oddaljeni repozitorij, ki ga uporabljajo druge osebe, ne potiskajte nobenih potrditev, ki še niso bile oddane na strežnik Perforce.
+Bodite previdni pri deljenju potrditev Git; če imate oddaljeni repozitorij, ki ga uporabljajo druge osebe, ne potiskajte nobenih potrditev, ki še niso bile predložene na strežnik Perforce.
 
 Če želite prosto mešati uporabo Perforce in Git kot odjemalcev za nadzor izvorne kode, in če lahko prepričate upravitelja strežnika, da ga namesti, lahko uporabite Git Fusion, ki omogoča uporabo Git kot odjemalca za strežnik Perforce.