Improve code highlighting up to chapter 7

progit · Apr 23, 2023 · e2c4064 · e2c4064
1 parent 35788b7
commit e2c4064
Show file tree

Hide file tree

Showing 18 changed files with 102 additions and 102 deletions.
diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc
@@ -152,7 +152,7 @@ $ git push --set-upstream origin main
 
 Sedaj imamo naslednje stanje:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git branch --all
 * main

diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc
@@ -352,7 +352,7 @@ $ git commit -am 'Add limit to log function'
 Na tej točki morate deliti nekaj dela z Johnom, torej potisne njene potrditve veje `featureA` na strežnik.
 Jessica nima dostopa potiskanja na vejo `master` - to imajo samo povezovalci - torej mora potisniti na drugo vejo, da lahko sodeluje z Johnom:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git push -u origin featureA
 ...
@@ -395,7 +395,7 @@ Pripravljena je potisniti njeno delo, vendar dobi e-pošto od Josie, da je veja
 Jessica mora najprej združiti te spremembe v njeno lastno, preden lahko potisne svoje delo na strežnik.
 Jessica najprej prenese spremembe Josie z `git fetch`:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git fetch origin
 ...
@@ -417,7 +417,7 @@ Merge made by the 'recursive' strategy.
 V tem trenutku Jessica želi vse združeno delo "`featureB`" potisniti nazaj na strežnik, vendar noče preprosto potisniti svoje veje `featureB`.
 Ker je Josie že začela z zgornjo vejo `featureBee`, želi Jessica potisniti na _to_ vejo, kar stori s:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git push -u origin featureB:featureBee
 ...
@@ -432,7 +432,7 @@ Bodite pozorni tudi na zastavico `-u`; to je okrajšava za `--set-upstream`, ki
 Nenadoma Jessica prejme e-pošto od Johna, ki ji sporoči, da je potisnil nekaj sprememb na vejo `featureA`, na kateri sodelujeta, in jo prosi, naj si jih ogleda.
 Ponovno Jessica zažene preprost ukaz `git fetch`, da prenese _vse_ nove vsebine s strežnika, vključno (seveda) z Johnovim najnovejšim delom:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git fetch origin
 ...
@@ -467,7 +467,7 @@ Fast forward
 
 Nazadnje bi Jessica lahko želela narediti nekaj manjših sprememb na vsem tem združenem delu, zato je prosta, da naredi te spremembe, jih potrdi v svoji lokalni veji `featureA` in potisne končni rezultat nazaj na strežnik:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git commit -am 'Add small tweak to merged content'
 [featureA 774b3ed] Add small tweak to merged content
@@ -671,7 +671,7 @@ Ukaz `format-patch` izpiše imena datotek popravka, ki ga ustvari.
 Preklop `-M` pove Gitu, da išče preimenovanja.
 Datoteke so na koncu videti takole:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ cat 0001-add-limit-to-log-function.patch
 From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
@@ -754,7 +754,7 @@ Kot prej, lahko nastavite vsako vrednost ločeno s serijo ukazov `git config`, a
 
 Ko je to narejeno, lahko uporabite `git send-email`, da pošljete svoje popravke:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git send-email *.patch
 0001-add-limit-to-log-function.patch

diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc
@@ -77,7 +77,7 @@ Da uporabite programski popravek generiran s `format-patch`, uporabite `git am`
 Tehnično je `git am` zgrajen, da prebere datoteko mbox, ki je enostaven tekstovni format za shranjevanje enega ali več e-poštnih sporočil v eni tekstovni datoteki.
 Videti je nekako takole:
 
-[source,console]
+[source,email]
 ----
 From 330090432754092d704da8e76ca5c05c198e71a8 Mon Sep 17 00:00:00 2001
 From: Jessica Smith <[email protected]>
@@ -103,7 +103,7 @@ Vidite lahko, da se je programski popravek uporabil brez težav in samodejno ust
 Informacije o avtorju so vzete iz glav `From` in `Date` v e-pošti, sporočilo potrditve pa je vzeto iz `Subject` in telesa (pred popravkom) e-pošte.
 Če je bil na primer ta programski popravek uporabljen iz zgornjega primera mbox, bi bila ustvarjena potrditev nekaj podobnega temu:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git log --pretty=fuller -1
 commit 6c5e70b984a60b3cecd395edd5b48a7575bf58e0
@@ -209,7 +209,7 @@ Druga prednost tega pristopa je, da dobite tudi zgodovino opravljenih potrditev.
 Če ne sodelujete redno z osebo, vendar še vedno želite povleči od njih na ta način, lahko naslov URL oddaljenega repozitorija navedete v ukazu `git pull`.
 To naredi enkratno vlečenje in ne shrani URL-ja kot referenčnega oddaljenega vira:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git pull https://github.com/onetimeguy/project
 From https://github.com/onetimeguy/project
@@ -230,7 +230,7 @@ Potrditve v veji `master` lahko izključite tako, da pred imenom veje dodate mo
 To stori isto kot oblika `master..contrib`, ki smo jo uporabili prej.
 Na primer, če vam sodelavec pošlje dve potrditvi in ustvarite vejo z imenom `contrib` ter nanjo uporabite te potrditve, lahko zaženete:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git log contrib --not master
 commit 5b6235bd297351589efc4d73316f0a68d484f118
@@ -433,7 +433,7 @@ Ko se odločite za izdajo, boste verjetno želeli dodeliti oznako, da boste lahk
 Novo oznako lahko ustvarite, kot je opisano v <<ch02-git-basics-chapter#ch02-git-basics-chapter>>.
 Če se odločite podpisati oznako kot vzdrževalec, je lahko postopek označevanja videti nekako takole:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git tag -s v1.5 -m 'my signed 1.5 tag'
 You need a passphrase to unlock the secret key for
@@ -445,7 +445,7 @@ user: "Scott Chacon <[email protected]>"
 Vzdrževalec projekta Git je to težavo rešil tako, da je svoj javni ključ vključil kot blob v repozitoriju in nato dodal oznako, ki neposredno kaže na ta vsebino.
 Kateri ključ želite, lahko ugotovite tako, da zaženete ukaz `gpg --list-keys`:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ gpg --list-keys
 /Users/schacon/.gnupg/pubring.gpg
@@ -535,7 +535,7 @@ Zdaj imate lep tarball in arhiv zip vaše projektne izdaje, ki ju lahko naložit
 Lep način hitrega pridobivanja vrste sprememb, ki so bile dodane v vaš projekt od zadnje objave ali e-pošte, je uporaba ukaza `git shortlog`.
 Povzame vse potrditve v določenem obsegu; na primer, naslednje vam da povzetek vseh potrditev od zadnje objave, če je bila vaša zadnja objava poimenovana `v1.0.1`:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git shortlog --no-merges master --not v1.0.1
 Chris Wanstrath (6):

diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc
@@ -70,7 +70,7 @@ Najprej kliknemo gumb "`Fork`", kot je že omenjeno, da dobimo lastno kopijo pro
 Naše uporabniško ime tukaj je "`tonychacon`", torej je naša kopija tega projekta na `https://github.com/tonychacon/blink`, kjer ga lahko urejamo.
 Lokalno ga bomo klonirali, ustvarili tematsko vejo, naredili spremembo v kodi in nazadnje to spremembo potisnili nazaj na GitHub.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git clone https://github.com/tonychacon/blink <1>
 Cloning into 'blink'...
@@ -243,7 +243,7 @@ Pomembna je zgodovina in končno združevanje, zato ponovno baziranje ne prinaš
 Na primer, recimo, da je prvotni avtor v primeru "`tonychacon`", ki smo ga uporabljali prej, naredil spremembo, ki bi povzročila konflikt v zahtevku potega.
 Pojdimo skozi te korake.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git remote add upstream https://github.com/schacon/blink <1>
 

diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc
@@ -154,7 +154,7 @@ To pomeni, da lahko precej enostavno povlečete vse veje zahtevka potega v enem
 
 Sedaj lahko na primer prenesete referenco neposredno.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git fetch origin refs/pull/958/head
 From https://github.com/libgit2/libgit2
@@ -193,7 +193,7 @@ To področje lahko spremenite in dodate nov refspec:
 Ta zadnja vrstica sporoči Gitu: "`Vse sklice, ki so videti kot `refs/pull/123/head`, naj se lokalno shrani kot `refs/remotes/origin/pr/123`.`"
 Če zdaj shranite to datoteko in izvedete `git fetch`:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git fetch
 # …
@@ -294,7 +294,7 @@ V glavah e-poštnih sporočil, ki jih GitHub pošilja, je tudi precejšnje štev
 
 Na primer, če si ogledamo dejanske glave e-pošte, ki jih GitHub pošilja Tonyju v e-poštnem sporočilu, prikazanem v <<_email_pr>>, bomo med poslano informacijo videli:
 
-[source,mbox]
+[source,email]
 ----
 To: tonychacon/fade <[email protected]>
 Message-ID: <tonychacon/fade/pull/[email protected]>

diff --git a/book/07-git-tools/sections/advanced-merging.asc b/book/07-git-tools/sections/advanced-merging.asc
@@ -38,7 +38,7 @@ hello()
 V svojem repozitoriju ustvarimo novo vejo, imenovano `whitespace` in nadaljujemo s spreminjanjem vseh končnic vrstic Unix v končnice vrstic DOS, torej dejansko spremenimo vsako vrstico datoteke, vendar le s praznimi znaki.
 Nato spremenimo vrstico "`hello world`" v "`hello mundo`".
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git checkout -b whitespace
 Switched to a new branch 'whitespace'
@@ -72,7 +72,7 @@ $ git commit -am 'Use Spanish instead of English'
 
 Sedaj preklopimo nazaj na našo vejo `master` in dodamo nekaj dokumentacije za funkcijo.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git checkout master
 Switched to branch 'master'
@@ -98,7 +98,7 @@ $ git commit -am 'Add comment documenting the function'
 
 Sedaj poskusimo združiti v našo vejo `whitespace` in dobimo konflikte zaradi sprememb praznih znakov.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git merge whitespace
 Auto-merging hello.rb
@@ -113,7 +113,7 @@ Zdaj imamo nekaj možnosti.
 Najprej se pogovorimo, kako iz te situacije priti ven.
 Če niste pričakovali konfliktov in se z njimi ne želite spopasti, lahko preprosto razveljavite združevanje z `git merge --abort`.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git status -sb
 ## master
@@ -194,7 +194,7 @@ $ git ls-files -u
 
 Sedaj, ko imamo vsebine vseh treh stopenj v svojem delovnem imeniku, lahko njihovo težavo praznih znakov ročno popravimo in poskusimo ponovno združiti datoteko z manj znanim ukazom `git merge-file`, ki počne ravno to.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ dos2unix hello.theirs.rb
 dos2unix: converting file hello.theirs.rb to Unix format ...
@@ -228,7 +228,7 @@ Pojdi skozi vse.
 
 Da primerjate svoj rezultat s tistim, kar ste imeli v svoji veji pred združitvijo, z drugimi besedami, da vidite, kaj je združitev uvedla, lahko zaženete `git diff --ours`:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git diff --ours
 * Unmerged path hello.rb
@@ -252,7 +252,7 @@ Tukaj lahko jasno vidimo, da se je v naši veji spremenila samo ta ena vrstica i
 Če želimo videti, kako se je rezultat združevanja razlikoval od tistega, kar je bilo na njihovi strani, lahko zaženemo `git diff --theirs`.
 V tem in naslednjem primeru moramo uporabiti `-b`, da odstranimo prazne znake, ker primerjamo s tem, kar je v Gitu in ne z našo očiščeno datoteko `hello.theirs.rb`.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git diff --theirs -b
 * Unmerged path hello.rb
@@ -271,7 +271,7 @@ index e85207e..44d0a25 100755
 
 Na koncu lahko z `git diff --base` vidite, kako se je datoteka spremenila iz obeh strani.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git diff --base -b
 * Unmerged path hello.rb
@@ -325,7 +325,7 @@ $ git log --graph --oneline --decorate --all
 Sedaj imamo tri unikatne potrditve, ki se nahajajo samo v veji `master` ter tri ostale, ki se nahajajo v veji `mundo`.
 Če poskusimo združiti vejo `mundo`, dobimo konflikt.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git merge mundo
 Auto-merging hello.rb
@@ -408,7 +408,7 @@ Včasih lahko zelo pomaga pregledati nekaj zgodovine, da se spomnite, zakaj sta
 
 Če želimo dobiti popoln seznam vseh edinstvenih potrditev, ki so bile vključene v katerokoli vejo, ki sodeluje pri tem združevanju, lahko uporabimo sintakso "`trojne pike`", ki smo se je naučili v <<ch07-git-tools#_triple_dot>>.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git log --oneline --left-right HEAD...MERGE_HEAD
 < f1270f7 Update README
@@ -424,7 +424,7 @@ To je dober seznam šestih vključenih skupnih potrditev, kot tudi na kateri vrs
 To lahko še bolj poenostavimo, da dobimo natančnejši kontekst.
 Če dodamo ukazu `git log` možnost `--merge`, bo prikazal samo tiste potrditve na vsaki strani združevanja, ki se dotikajo datoteke, ki je trenutno v konfliktu.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git log --oneline --left-right --merge
 < 694971d Update phrase to 'hola world'
@@ -441,7 +441,7 @@ To lahko pomaga pri ogledu tega, kar morate še rešiti.
 
 Ko zaženete `git diff` neposredno po konfliktnem združevanju, vam bo dala informacije v dokaj edinstveni obliki izpisa diff.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git diff
 diff --cc hello.rb
@@ -470,7 +470,7 @@ To ima smisel, saj jih je orodje za združevanje tam postavilo za naš kontekst,
 
 Če rešimo konflikt in znova zaženemo `git diff`, bomo videli isto stvar, vendar je to nekoliko bolj uporabno.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ vim hello.rb
 $ git diff
@@ -496,7 +496,7 @@ To lahko pomaga pri pregledu pred potrditvijo rešitve.
 To lahko dobite tudi iz `git log` za vsako združitev, da vidite, kako je bila neka težava v resnici rešena.
 Git bo izpisal to obliko, če na potrditvi združitve zaženete `git show`, ali pa če dodate možnost `--cc` h `git log -p` (ki privzeto prikazuje popravke samo za potrditve nezdružitev).
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git log --cc -p -1
 commit 14f41939956d80b9e17bb8721354c33f8d5b5a79
@@ -630,7 +630,7 @@ Vse razlike, ki se konfliktno prekrivajo, bo preprosto izbral celotno stran, ki
 
 Če se vrnemo na primer "`hello world`", ki smo ga uporabljali prej, lahko vidimo, da združitev naše veje povzroči konflikt.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git merge mundo
 Auto-merging hello.rb

diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc
@@ -16,7 +16,7 @@ Ukaz `bundle` bo vse, kar bi sicer bilo poslano po žici z ukazom `git push`, za
 Poglejmo si preprost primer.
 Recimo, da imate repozitorij s tremi potrditvami:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git log
 commit 9a466c572fe88b195efd356c3f2bbeccdb504102
@@ -147,7 +147,7 @@ Podukaz `verify` vam bo prav tako povedal, katere glave so na voljo.
 Namen je videti, kaj lahko povlečete, zato lahko uporabite ukaza `fetch` ali `pull`, da uvozite potrditve iz te zbirke.
 Tukaj bomo pridobili vejo `master` zbirke v vejo imenovano `other-master` v našem repozitoriju:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git fetch ../commits.bundle master:other-master
 From ../commits.bundle

diff --git a/book/07-git-tools/sections/debugging.asc b/book/07-git-tools/sections/debugging.asc
@@ -12,7 +12,7 @@ Prikaže vam, katera potrditev je bila zadnja, ki je spremenila vsako vrstico v
 
 V spodnjem primeru `git blame` določa, katera potrditev in avtor sta bila odgovorna za vrstice v glavnem jedru Linux datoteke `Makefile`, in še dodatno uporablja možnost `-L`, da omeji izpis anotacije na vrstice od 69 do 82 v tej datoteki:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git blame -L 69,82 Makefile
 b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 69) ifeq ("$(origin V)", "command line")
@@ -44,7 +44,7 @@ Ena od zanimivih lastnosti tega je, da lahko zaprosite, naj ugotovi vse vrste pr
 Na primer, recimo, da preoblikujete datoteko imenovano `GITServerHandler.m` v več datotek, ena izmed njih pa je `GITPackUpload.m`.
 S pomočjo možnosti `-C` lahko označite `GITPackUpload.m` in vidite, od kod so bili prvotno vzeti odseki kode:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git blame -C -L 141,153 GITPackUpload.m
 f344f58d GITServerHandler.m (Scott 2009-01-04 141)
@@ -113,7 +113,7 @@ Bisecting: 1 revisions left to test after this
 Ta potrditev je v redu in zdaj ima Git vse informacije, ki jih potrebuje, da ugotovi, kje je bil vnesen problem.
 Pove vam SHA-1 prve slabe potrditve in prikaže nekatere informacije o potrditvi ter katere datoteke so bile spremenjene v tej potrditvi, tako da lahko ugotovite, kaj se je zgodilo, da bi lahko uvedlo to napako:
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git bisect good
 b047b02ea83310a70fd603dc8cd7a6cd13d15c04 is first bad commit