Further proofread chapter 10

Author: petk

C-git-commands.asc

@@ -536,7 +536,7 @@ Ta ukaz je podrobno opisan v razdelku <<ch09-git-and-other-systems#_custom_impor
 
 === Administracija
 
-Če upravljate repozitorij Git ali morate nekaj popraviti na velik način, Git zagotavlja številne upravljavske ukaze, ki vam lahko pomagajo.
+Če upravljate repozitorij Git ali morate nekaj popraviti na velik način, Git ponuja številne upravljavske ukaze, ki vam lahko pomagajo.
 
 ==== git gc
 

book/01-introduction/sections/first-time-setup.asc

@@ -73,7 +73,7 @@ $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -m
 
 [NOTE]
 ====
-Vim, Emacs in Notepad++ so popularni urejevalniki besedil pogosto uporabljeni s strani razvijalcev na sistemih osnovanih na Unixu, kot sta Linux in macOS ali na sistemu Windows.
+Vim, Emacs in Notepad++ so popularni urejevalniki besedil pogosto uporabljeni s strani razvijalcev na sistemih osnovanih na Unix-u, kot sta Linux in macOS ali na sistemu Windows.
 Če uporabljate drug urejevalnik ali 32-bitno različico, prosimo, poiščite specifična navodila, kako nastaviti vaš priljubljeni urejevalnik z Gitom v <<C-git-commands#ch_core_editor>>.
 ====
 

book/01-introduction/sections/installing.asc

@@ -29,7 +29,7 @@ $ sudo dnf install git-all
 $ sudo apt install git-all
 ----
 
-Za več možnosti so na voljo navodila za namestitev na nekaj različnih okusih Unixa na spletni strani Git, na https://git-scm.com/download/linux[^].
+Za več možnosti so na voljo navodila za namestitev na nekaj različnih okusih Unix-a na spletni strani Git, na https://git-scm.com/download/linux[^].
 
 ==== Namestitev na macOS
 

book/04-git-server/sections/generating-ssh-key.asc

@@ -3,7 +3,7 @@
 
 (((Ključi SSH)))
 Mnogi strežniki Git izvajajo overjanje z uporabo javnih ključev SSH.
-Da se javni ključ zagotovi, ga mora generirati vsak uporabnik v vašem sistemu, če ga še nima.
+Da se ponudi javni ključ, ga mora generirati vsak uporabnik v vašem sistemu, če ga še nima.
 Ta proces je podoben v vseh operacijskih sistemih.
 Najprej morate preveriti, da zagotovite, da nimate že ključa.
 Privzeto so uporabniški ključi SSH shranjeni v uporabnikovem direktoriju `~/.ssh`.

book/04-git-server/sections/protocols.asc

@@ -201,7 +201,7 @@ Zaradi pomanjkanja TLS ali druge kriptografije lahko kloniranje prek `git://` pr
 * Če zaženete `git clone git://example.com/project.git`, lahko napadalec, ki nadzoruje vaš usmerjevalnik, spremeni pred kratkim kloniran repozitorij in vanj vstavi zlonamerno kodo.
   Če nato prevedete/zaženete kodo, ki ste jo pravkar klonirali, bo izvedena tudi zlonamerna koda.
   Zaradi istega razloga se je treba izogibati tudi zagonu `git clone http://example.com/project.git`.
-* Zagon `git clone https://example.com/project.git` nima take težave (razen če napadalec lahko zagotovi certifikat TLS za example.com).
+* Zagon `git clone https://example.com/project.git` nima take težave (razen če napadalec lahko poda certifikat TLS za example.com).
   Zagon `git clone [email protected]:project.git` ima težavo samo, če sprejmete napačni prstni odtis SSH.
 
 Protokol Git tudi nima overjanja, torej lahko repozitorij klonira kdorkoli (čeprav je to pogosto prav tisto, kar želite).

book/05-distributed-git/sections/maintaining.asc

@@ -282,7 +282,7 @@ ali bolj jedrnato:
 $ git diff $(git merge-base contrib master)
 ----
 
-Vendar nobena od teh ni posebej priročna, zato Git zagotavlja še eno bližnjico za isto stvar: sintakso s tremi pikami.
+Vendar nobena od teh ni posebej priročna, zato Git ponuja še eno bližnjico za isto stvar: sintakso s tremi pikami.
 V kontekstu ukaza `git diff` lahko dodate tri pike po drugi veji, da naredite `diff` med zadnjo potrditvijo na veji, na kateri ste, in njenim skupnim prednikom z drugo vejo:
 
 [source,console]

book/06-github/sections/1-setting-up-account.asc

@@ -94,4 +94,4 @@ image::images/2fa-1.png[2FA v zavihku »Security«]
 
 Če kliknete na gumb »Set up two-factor authentication«, vas bo popeljalo na nastavitveno stran, kjer lahko izberete uporabo telefonske aplikacije, da se zgenerira vaša drugotna koda (»časovno osnovano enkratno geslo«), lahko pa nastavite, da vam GitHub pošlje kodo preko SMS-a vsakič, ko se morate prijaviti.
 
-Ko izberete, katero metodo imate raje, in sledite navodilom za nastavitev 2FA, bo vaš račun malo varnejši ter vsakič, ko se boste prijavili v GitHub, boste morali zagotoviti tudi kodo poleg svojega gesla.
+Ko izberete, katero metodo imate raje, in sledite navodilom za nastavitev 2FA, bo vaš račun malo varnejši ter vsakič, ko se boste prijavili v GitHub, boste morali ponuditi tudi kodo poleg svojega gesla.

book/06-github/sections/2-contributing.asc

@@ -185,7 +185,7 @@ Zanimivo je opaziti, da če kliknete na zavihek »Files Changed« na tem zahtevk
 V pojmu `git diff` vam to v bistvu avtomatično prikaže `git diff master...<branch>` za vejo, na kateri temelji ta zahtevek potega.
 Za več informacij o tej vrsti razlike si oglejte razdelek <<ch05-distributed-git#_what_is_introduced>>.
 
-Druga stvar, ki jo boste opazili, je, da GitHub preveri, ali se zahtevek potega združi brez težav, in zagotovi gumb za izvedbo združevanja na strežniku.
+Druga stvar, ki jo boste opazili, je, da GitHub preveri, ali se zahtevek potega združi brez težav, in ponudi gumb za izvedbo združevanja na strežniku.
 Ta gumb se prikaže le, če imate dostop za pisanje v repozitoriju in če je mogoča trivialna združitev.
 Če nanj kliknete, bo GitHub izvedel združitev »non-fast-forward«, kar pomeni, da bo ustvaril potrditev združitve, tudi če *bi lahko* združitev bila hitro previta naprej.
 

book/06-github/sections/3-maintaining.asc

@@ -308,7 +308,7 @@ X-GitHub-Recipient-Address: [email protected]
 ----
 
 Obstaja nekaj zanimivih stvari.
-Če želite poudariti ali preusmeriti e-pošto na ta določeni projekt ali celo zahtevati potrditev povratne informacije za točno ta projekt ali celo zahtevek potega, vam podatki v `Message-ID` zagotavljajo vse podatke v formatu `<uporabnik>/<projekt>/<vrsta>/<id>`.
+Če želite poudariti ali preusmeriti e-pošto na ta določeni projekt ali celo zahtevati potrditev povratne informacije za točno ta projekt ali celo zahtevek potega, vam podatki v `Message-ID` ponujajo vse podatke v formatu `<uporabnik>/<projekt>/<vrsta>/<id>`.
 Če bi bila to na primer težava, bi bilo polje `<vrsta>` »issues« namesto »pull«.
 
 Polji `List-Post` in `List-Unsubscribe` pomenita, da lahko, če imate poštni odjemalec, ki ju razume, enostavno pošljete sporočilo na seznam ali se »odjavite« iz niti.

book/07-git-tools/sections/credentials.asc

@@ -21,7 +21,7 @@ Git ima vgrajenih nekaj možnosti:
   Ta metoda poverilnice shrani na disk in ne potečejo, vendar so šifrirane s sistemom, ki shranjuje certifikate HTTPS, ter Safari jih samodejno izpolnjuje.
 * Če uporabljate Windows, lahko omogočite funkcijo *Git Credential Manager* pri namestitvi https://gitforwindows.org/[Git za Windows] ali ločeno namestite https://github.com/git-ecosystem/git-credential-manager/releases/latest[najnovejši GCM] kot samostojno storitev.
   To je podobno pomočniku »osxkeychain« opisanem zgoraj, vendar uporablja shrambo poverilnic sistema Windows za nadzor občutljivih informacij.
-  Lahko tudi zagotavlja poverilnice za WSL1 ali WSL2.
+  Ponuja lahko tudi poverilnice za WSL1 ali WSL2.
   Za več informacij glejte https://github.com/git-ecosystem/git-credential-manager#readme[navodila za namestitev GCM].
 
 Izmed teh metod lahko izberete eno z nastavitvijo konfiguracijske vrednosti Git:
@@ -113,7 +113,7 @@ Protokol stdin/stdout je enak kot pri git-credential, vendar uporablja nekoliko
 
 Za akciji `store` in `erase` ni zahtevan noben odziv (Git ga vseeno ignorira).
 Za akcijo `get` pa je Git zelo zainteresiran, za kar ima pomočnik sporočiti.
-Če pomočnik ne ve ničesar uporabnega, lahko preprosto izstopi brez izhoda, če pa ve, bi moral zagotoviti informacije, ki jih ima shranjene, in jih združiti s podatki, ki jih je Git že vedel.
+Če pomočnik ne ve ničesar uporabnega, lahko preprosto izstopi brez izhoda, če pa ve, bi moral ponuditi informacije, ki jih ima shranjene, in jih združiti s podatki, ki jih je Git že vedel.
 Izhod se obravnava kot niz dodelitvenih stavkov; karkoli je podano, bo nadomestilo, kar Git že ve.
 
 Tukaj je isti primer kot zgoraj, vendar preskočimo `git-credential` in gremo naravnost na `git-credential-store`:

book/07-git-tools/sections/debugging.asc

@@ -136,7 +136,7 @@ $ git bisect reset
 
 To je zmogljivo orodje, ki vam lahko v nekaj minutah pomaga preveriti na stotine potrditev za napako, ki je bila vnesena.
 Pravzaprav, če imate skript, ki se bo zaključil z 0, če je projekt v redu, ali neničelno vrednostjo, če je projekt slab, lahko `git bisect` v celoti izvedete samodejno.
-Najprej mu spet sporočite obseg ukaza `bisect` tako, da zagotovite znane slabe in dobre potrditve.
+Najprej mu spet sporočite obseg ukaza `bisect` tako, da podate znane slabe in dobre potrditve.
 To lahko storite tako, da jih navedete z ukazom `bisect start`, če želite, tako da najprej navedete znano slabo potrditev, drugo znano dobro potrditev pa drugo:
 
 [source,console]

book/07-git-tools/sections/submodules.asc

@@ -666,7 +666,7 @@ Torej, kar se je tu zgodilo, je, da je Git ugotovil, da se točke v zgodovini po
 Pojasni, kot »združitve naslednjih potrditev niso bile najdene«, kar je zmedeno, vendar bomo to pojasnili malo kasneje.
 
 Za rešitev problema morate ugotoviti, v katerem stanju naj bo podmodul.
-Presenetljivo Git ne zagotavlja veliko informacij, ki bi pomagale pri tem, niti SHA-1 potrditev obeh strani zgodovine.
+Presenetljivo Git ne ponuja veliko informacij, ki bi pomagale pri tem, niti SHA-1 potrditev obeh strani zgodovine.
 Na srečo je to preprosto ugotoviti.
 Če zaženete `git diff`, lahko dobite SHA-1 potrditve, posnete v obeh vejah, ki jih poskušate združiti.
 

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

@@ -15,14 +15,14 @@ Druga možnost pa je git-p4, most na strani odjemalca, ki vam omogoča uporabo G
 ===== Git Fusion
 
 (((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.
+Perforce ponuja 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.
 
 ====== 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).
 
-Ob prvem zagonu naprave vas prosi, da prilagodite geslo za tri uporabnike v sistemu Linux (`root`, `perforce` in `git`) ter zagotovite ime instance, ki se lahko uporabi za razlikovanje te namestitve od drugih v istem omrežju.
+Ob prvem zagonu naprave vas prosi, da prilagodite geslo za tri uporabnike v sistemu Linux (`root`, `perforce` in `git`) ter podate ime instance, ki se lahko uporabi za razlikovanje te namestitve od drugih v istem omrežju.
 Ko je vse to dokončano, boste videli to:
 
 .Zagonski zaslon virtualne naprave Git Fusion

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

@@ -381,7 +381,7 @@ Za izogibanje težavam morate po združitvi veje v `trunk` izbrisati lokalno vej
 
 ===== Ukazi Subversion
 
-Orodja `git svn` zagotavljajo nekaj ukazov, ki pomagajo olajšati prehod na Git s funkcionalnostjo, ki je podobna tisti, ki ste jo imeli v Subversionu.
+Orodja `git svn` ponujajo nekaj ukazov, ki pomagajo olajšati prehod na Git s funkcionalnostjo, ki je podobna tisti, ki ste jo imeli v Subversionu.
 Tu je nekaj ukazov, ki vam dajo tisto, kar ste imeli v Subversionu.
 
 ====== Zgodovina v stilu SVN

book/10-git-internals/sections/maintenance.asc

@@ -181,7 +181,7 @@ Ker je dostopna iz zgodovine, bo vedno tam.
 
 To lahko predstavlja velik problem, ko pretvarjate repozitorije Subversion ali Perforce v Git.
 Ker v teh sistemih ne prenesete celotne zgodovine, ta vrsta dodatka ne povzroča veliko posledic.
-Če ste uvozili iz drugega sistema ali našli drug način, da je vaš repozitorij veliko večji, kot bi moralo biti, vam predstavljamo, kako najti in odstraniti velike objekte.
+Če ste uvozili iz drugega sistema ali našli drug način, da je vaš repozitorij veliko večji, kot bi moral biti, vam predstavljamo, kako najti in odstraniti velike objekte.
 
 *Opozorilo: ta tehnika lahko uniči vašo zgodovino potrditev.*
 Prepiše vsak objekt potrditve od najstarejšega drevesa naprej, da odstrani sklice na veliko datoteko.

book/10-git-internals/sections/objects.asc

@@ -123,7 +123,7 @@ blob
 ==== Drevesni objekti
 
 Naslednjo vrsto objekta Git, ki jo bomo pregledali, je drevo (angl. _tree_), ki rešuje problem shranjevanja imena datoteke in vam omogoča, da skupino datotek shranite skupaj.
-Git vsebino shranjuje na način, podoben UNIX-ovi datotečni strukturi, vendar nekoliko poenostavljen.
+Git vsebino shranjuje na način, podoben UNIX-ovi datotečni strukturi, vendar nekoliko poenostavljeno.
 Vse vsebine so shranjene kot objekti dreves in blobov, pri čemer drevesa ustrezajo vnosom v UNIX-ovem imeniku, blobi pa približno ustrezajo inodom ali vsebini datotek.
 Posamezni objekt drevesa vsebuje enega ali več vnosov, pri čemer je vsak vnos zgoščene vrednosti SHA-1 koda bloba ali poddrevesa s pripadajočim načinom, vrsto in imenom datoteke.
 Na primer, recimo, da imate projekt, kjer je zadnje drevo videti nekako takole:
@@ -259,7 +259,7 @@ fdf4fc3344e67ab068f836878b6c4951e3b15f3d
 
 [NOTE]
 ====
-Zdaj boste dobili drugačno vrednost zgoščene vrednosti zaradi različnega časa ustvarjanja in avtorskih podatkov.
+Zdaj boste dobili drugačno zgoščeno vrednost zaradi različnega časa ustvarjanja in avtorskih podatkov.
 Poleg tega, čeprav se lahko v teoriji vsak objekt potrditve natančno reproducira s temi podatki, zgodovinski podatki o gradnji te knjige pomenijo, da se natisnjene zgoščene vrednosti potrditve morda ne ujemajo z določenimi potrditvami.
 V tem poglavju nadomestite zgoščene vrednosti potrditve in oznak s svojimi kontrolnimi vsotami.
 ====

book/10-git-internals/sections/packfiles.asc

@@ -1,4 +1,4 @@
-=== Packfiles
+=== Packfiles (datoteke zmanjšanih podatkov)
 
 Če ste sledili vsem navodilom v primeru iz prejšnjega odseka, bi morali imeti zdaj testni repozitorij Git z 11 objekti -- štirimi blobi, tremi drevesi, tremi potrditvami in eno oznako:
 
@@ -35,7 +35,7 @@ $ git commit -m 'Create repo.rb'
  rewrite test.txt (100%)
 ----
 
-Če si ogledate izhajajoče drevo, lahko vidite vrednost SHA-1, ki je bila izračunana za vaš novi blob objekt `repo.rb`:
+Če si ogledate izhajajoče drevo, lahko vidite vrednost SHA-1, ki je bila izračunana za vaš novi objekt blob `repo.rb`:
 
 [source,console]
 ----
@@ -113,9 +113,9 @@ $ find .git/objects -type f
 ----
 
 Objekti, ki ostanejo, so blobi, na katere ne kaže nobena potrditev -- v tem primeru bloba »what is up, doc?« in »test content«, ki ste ju ustvarili prej.
-Ker jih nikoli niste dodali k nobeni potrditvi, se štejejo za viseče in niso zapakirani v vaši novi packfile.
+Ker jih nikoli niste dodali k nobeni potrditvi, se štejejo za viseče (angl. _dangling_) in niso zapakirani v vaši novi packfile.
 
-Druge datoteke sta vaša nova packfile in indeks.
+Druge datoteke so vaša nova packfile in indeks.
 Datoteka zmanjšanih podatkov (packfile) je ena sama datoteka, ki vsebuje vsebino vseh objektov, ki so bili odstranjeni iz vašega datotečnega sistema.
 Indeks je datoteka, ki vsebuje zamike v tej zmanjšani datoteki, da lahko hitro poiščete določen objekt.
 Kar je odlično, je to, da čeprav so objekti na disku pred zagonom ukaza `gc` zavzemali približno 15 K v velikosti, nova zmanjšana datoteka zavzema samo 7 K.

book/10-git-internals/sections/plumbing-porcelain.asc

@@ -1,8 +1,8 @@
 [[_plumbing_porcelain]]
 === Napeljava in keramika
 
-Ta knjiga pokriva, kako uporabljati Git s 30 ali nekaj podukazov, kot so `checkout`, `branch`, `remote` itd.
-Vendar ker je bil Git prvotno orodje za nadzor različic namesto polnega uporabniku prijaznega VCS-ja, ima kopico podukazov, ki delajo nižje nivojsko delo in so bili načrtovani za veriženje skupaj v stilu UNIXa oz. so klicani iz skriptov.
+Ta knjiga pokriva, kako uporabljati Git s 30 ali nekaj podukazi, kot so `checkout`, `branch`, `remote` itd.
+Vendar ker je bil Git prvotno orodje za nadzor različic namesto polnega uporabniku prijaznega VCS-ja, ima kopico podukazov, ki delajo nižje nivojsko delo in so bili načrtovani za veriženje skupaj v stilu UNIX-a oz. so klicani iz skriptov.
 Ti ukazi so v splošnem imenovani kot Gitovi ukazi »napeljave«, medtem ko so bolj uporabniku prijazni ukazi imenovani ukazi »keramike«.
 
 Kot ste do sedaj opazili, se prvih devet poglavij knjige ukvarja skoraj ekskluzivno z ukazi keramike.

book/10-git-internals/sections/refs.asc

@@ -1,7 +1,7 @@
 [[_git_refs]]
 === Reference Git
 
-Če vas zanima ogled zgodovine vašega repozitorija, katera je dosegljivega od potrditve `1a410e`, bi lahko zagnali nekaj podobnega kot `git log 1a410e`, da bi prikazali to zgodovino, vendar bi si še vedno morali zapomniti, da je `1a410e` tista potrditev, ki jo želite uporabiti kot začetno točko za to zgodovino.
+Če vas zanima ogled zgodovine vašega repozitorija, katera je dosegljiva od potrditve `1a410e`, bi lahko zagnali nekaj podobnega kot `git log 1a410e`, da bi prikazali to zgodovino, vendar bi si še vedno morali zapomniti, da je `1a410e` tista potrditev, ki jo želite uporabiti kot začetno točko za to zgodovino.
 Namesto tega bi bilo lažje, če bi imeli datoteko, v kateri bi lahko shranili tisto vrednost SHA-1 pod preprostim imenom, tako da bi lahko uporabili to preprosto ime namesto surove vrednosti SHA-1.
 
 V Gitu se ta preprosta imena imenujejo »reference« ali »refs«; datoteke, ki vsebujejo te vrednosti SHA-1, lahko najdete v imeniku `.git/refs`.
@@ -16,7 +16,7 @@ $ find .git/refs
 $ find .git/refs -type f
 ----
 
-Da ustvarite novo referenco, ki vam si bo pomagala zapomniti, kje je vaša zadnja potrditev, lahko teoretično naredite nekaj tako preprostega kot to:
+Da ustvarite novo referenco, ki si vam bo pomagala zapomniti, kje je vaša zadnja potrditev, lahko teoretično naredite nekaj tako preprostega kot to:
 
 [source,console]
 ----
@@ -33,7 +33,7 @@ cac0cab538b970a37ea1e769cbbde608743bc96d Second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d First commit
 ----
 
-Ne spodbujamo vas, da neposredno urejate datoteke z referencami; namesto tega Git zagotavlja varnejši ukaz `git update-ref`, če želite posodobiti referenco:
+Ne spodbujamo vas, da neposredno urejate datoteke z referencami; namesto tega Git ponuja varnejši ukaz `git update-ref`, če želite posodobiti referenco:
 
 [source,console]
 ----
@@ -74,7 +74,7 @@ Običajno je datoteka HEAD simbolična referenca na trenutno vejo.
 S simbolično referenco mislimo, da vsebuje kazalec na drugo referenco, v nasprotju z običajno referenco.
 
 Vendar pa v nekaterih redkih primerih datoteka HEAD vsebuje vrednost SHA-1 objekta Git.
-To se zgodi, ko izvlečete oznako, potrditev ali oddaljeno vejo, kar postavi vaš repozitorij v https://git-scm.com/docs/git-checkout#_detached_head[stanje ločene glave^].
+To se zgodi, ko izvlečete oznako, potrditev, ali oddaljeno vejo, kar postavi vaš repozitorij v https://git-scm.com/docs/git-checkout#_detached_head[stanje ločene glave^].
 
 Če pogledate datoteko, boste običajno videli nekaj takega:
 
@@ -94,7 +94,7 @@ ref: refs/heads/test
 
 Ko zaženete `git commit`, to ustvari objekt potrditve in določi nadrejeno tega objekta potrditve na vrednost SHA-1, na katero referenca v datoteki HEAD kaže.
 
-Datoteko lahko tudi ročno uredite, vendar obstaja tudi tukaj varnejši ukaz, ki to omogoča: `git symbolic-ref`.
+Datoteko lahko uredite tudi ročno, vendar obstaja tudi tukaj varnejši ukaz, ki to omogoča: `git symbolic-ref`.
 Vrednost datoteke HEAD lahko preberete s tem ukazom:
 
 [source,console]
@@ -206,4 +206,4 @@ ca82a6dff817ec66f44342007202690a93763949
 
 Oddaljene reference se razlikujejo od vej (reference `refs/heads`) predvsem v tem, da so obravnavane kot samo za branje.
 Z `git checkout` se jih lahko izvleče, vendar Git ne bo simbolno referenciral HEAD nanje, zato jih nikoli ne boste posodobili z ukazom `commit`.
-Git jih upravlja kot zaznamke zadnjega znanega stanja, kjer so te veje bile na teh strežnikih.
+Git jih upravlja kot zaznamke zadnjega znanega stanja, kjer so bile te veje na teh strežnikih.