Upstream changes

B-embedding-git-in-your-applications.asc

@@ -15,3 +15,6 @@ include::book/B-embedding-git/sections/libgit2.asc[]
 include::book/B-embedding-git/sections/jgit.asc[]
 
 include::book/B-embedding-git/sections/go-git.asc[]
+
+include::book/B-embedding-git/sections/dulwich.asc[]
+

Rakefile

@@ -45,7 +45,10 @@ namespace :book do
 
     `cp progit.asc progit.asc.bak`
     begin
-      version_string = ENV['TRAVIS_TAG'] || '0'
+      version_string = ENV['TRAVIS_TAG'] || `git describe --tags`.chomp
+      if version_string.empty?
+        version_string = '0'
+      end
       text = File.read('progit.asc')
       new_contents = text.gsub("$$VERSION$$", version_string).gsub("$$DATE$$", Time.now.strftime("%Y-%m-%d"))
       File.open("progit.asc", "w") {|file| file.puts new_contents }

TRANSLATING.md

@@ -38,6 +38,7 @@ Indonesian | [progit/progit2-id](https://github.com/progit/progit2-id)
 Italiano   | [progit/progit2-it](https://github.com/progit/progit2-it)
 日本語   | [progit/progit2-ja](https://github.com/progit/progit2-ja)
 한국어   | [progit/progit2-ko](https://github.com/progit/progit2-ko)
+Македонски | [progit2-mk/progit2](https://github.com/progit2-mk/progit2)
 Bahasa Melayu| [progit2-ms/progit2](https://github.com/progit2-ms/progit2)
 Nederlands | [progit/progit2-nl](https://github.com/progit/progit2-nl)
 Polski | [progit2-pl/progit2-pl](https://github.com/progit2-pl/progit2-pl)

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

@@ -13,8 +13,10 @@ Git пристига с инструмент наречен `git config`, кой
   Ако изпълните командата `git config` с параметър `--system`, тя чете и пише в този файл.
   (Понеже това е системен конфигурационен файл, ще се нуждаете от административни права за да го променяте.)
 2. `~/.gitconfig` или `~/.config/git/config` файл: Специфичен само за конкретния потребител.
-  Git чете и пише в този файл ако горната команда е изпълнена с параметъра `--global`.
+  Git чете и пише в този файл ако горната команда е изпълнена с параметъра `--global` и това засяга _всички_ хранилища, с които работите на дадена система.
 3. `config` файл в конкретна Git директория (`.git/config`) в произволно хранилище, което ползвате: Съдържа настройки само за това конкретно хранилище.
+  Може да накарате Git да чете и пише в този файл с опцията `--local`, но това всъщност се прави по подразбиране.
+  (Разбира се, трябва да сте в директория с Git хранилище, за да работи това коректно.)
 
 Всяко ниво от горните е с приоритет пред предишното, така че стойностите в `.git/config` се използват вместо аналогичните в `/etc/gitconfig`.
 

book/02-git-basics/sections/getting-a-repository.asc

@@ -74,7 +74,7 @@ $ git clone https://github.com/libgit2/libgit2
 Командата ще създаде директория с име `libgit2`, ще инициализира `.git` под-директория, ще изтегли на компютъра ви всички данни от това хранилище и ще ви даде всички файлове от последната работеща версия.
 Ако влезнете в новата папка `libgit2`, ще видите файловете вътре - готови за работа по тях.
 
-Ако желаете клонирането да е в директория с различно име - можете да го подадете като следващ параметър към командата:
+Ако желаете клонирането да е в директория с различно от `libgit2` име - можете да го подадете като следващ параметър към командата:
 
 [source,console]
 ----

book/02-git-basics/sections/viewing-history.asc

@@ -285,7 +285,7 @@ $ git log -S function_name
 
 [source,console]
 ----
-$ git log --pretty="%h - %s" --author=gitster --since="2008-10-01" \
+$ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" \
    --before="2008-11-01" --no-merges -- t/
 5610e3b - Fix testcase failure when extended attributes are in use
 acd3b9e - Enhance hold_lock_file_for_{update,append}() API

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -174,9 +174,6 @@ image::images/basic-merging-1.png[Три snapshot-а използвани в т
 .Сливащ commit
 image::images/basic-merging-2.png[Сливащ commit.]
 
-Заслужава си да отбележим също така, че Git определя най-добрия общ предшественик за база на сливането; това е различно от начина на работа в CVS или Subversion (преди версия 1.5), където разработчикът правещ сливането трябва сам да определи най-добрата изходна точка за сливането.
-Това прави сливането в Git много по-лесно, отколкото в другите системи.
-
 Сега, когато работата ви е слята, вече не се нуждаете от клона `iss53`.
 Можете да затворите тикета в ticket-tracking системата и да изтриете клона:
 

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

@@ -4,7 +4,7 @@
 (Под клон, разклонение и branch ще имаме предвид едно и също нещо.)
 За да разберем как в действителност Git реализира разклоненията, трябва да се върнем стъпка назад и да си припомним как Git съхранява своите данни.
 
-Както може би помните от <<ch01-getting-started#ch01-getting-started>>, Git не съхранява информацията си като серии от промени или разлики, а вместо това пази серии от моментното състояние на проекта - snapshots.
+Както може би помните от <<ch01-getting-started#ch01-getting-started>>, Git не съхранява информацията си като серии от промени или разлики, а вместо това пази серии от моментното състояние на проекта - _snapshots_.
 
 Когато правите къмит, Git съхранява един commit обект, който съдържа указател към snapshot-а на индексираното съдържание (това, което е в индексната област).
 Този обект също така съдържа името и имейла на автора, къмит съобщението и също така - указатели към къмита или къмитите, които са правени директно преди текущия къмит (тоест, неговите родител/родители): първоначалният къмит няма родители, нормалният къмит има един родител, а къмитът създаден в резултат от сливане на няколко клона има множество родители.
@@ -52,7 +52,7 @@ image::images/branch-and-history.png[branch и неговата commit исто
 (((branches, creating)))
 Какво се случва, когато създадете нов клон от кода?
 Git просто създава нов указател за вас, който да може да се премества.
-Да кажем, че създавате клон с име testing.
+Да кажем, че създавате клон с име `testing`.
 Това се прави с командата `git branch`:(((git commands, branch)))
 
 [source,console]

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

@@ -23,7 +23,7 @@ config            id_dsa.pub
 
 [source,console]
 ----
-$ ssh-keygen
+$ ssh-keygen -o
 Generating public/private rsa key pair.
 Enter file in which to save the key (/home/schacon/.ssh/id_rsa):
 Created directory '/home/schacon/.ssh'.
@@ -36,6 +36,8 @@ d0:82:24:8e:d7:f1:bb:9b:33:53:96:93:49:da:9b:e3 [email protected]
 ----
 
 Програмата първо пита къде да съхранява ключа (`.ssh/id_rsa`) и след това пита два пъти за парола, която можете да оставите празна, ако не желаете да я въвеждате всеки път, когато използвате ключа.
+Обаче, ако използвате парола, уверете се че сте добавили флага `-o`; това ще съхрани частния ключ във формат, който е по-устойчив на brute-force атаки за пароли в сравнение с формата по подразбиране.
+Може също да използвате `ssh-agent` инструмента за да избегнете въвеждането на паролата всеки път.
 
 След това, всеки потребител трябва да изпрати публичния си ключ на вас или който администрира Git сървъра (подразбираме, че използвате схема, при която SSH сървърът изисква публични ключове).
 Всичко което трябва да се направи е да се копира съдържанието на `.pub` файла и да се изпрати по имейл.

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

@@ -8,7 +8,7 @@
 ==== Работа в Topic клонове
 
 (((branches, topic)))
-Когато мислите да интегрирате новополучени промени, добра идея е да ги изпробвате в topic клон -- временен такъв създаден специално за теста.
+Когато мислите да интегрирате новополучени промени, добра идея е да ги изпробвате в _topic клон_ -- временен такъв създаден специално за теста.
 По такъв начин е лесно да поправите пач индивидуално и да го зарежете, ако той не работи, докато имате време да го разгледате по-подробно.
 Ако създадете клон с име съответстващо на темата на изпратената работа, например `ruby_client` или нещо подобно, можете лесно да го запомните и по-късно да се върнете в него.
 Поддръжникът на Git проекта например, дори се стреми да използва namespaces за тези имена -- като `sc/ruby_client`, където `sc` е съкращение за човека, който е изпратил работата.

book/07-git-tools/sections/advanced-merging.asc

@@ -19,7 +19,7 @@
 Преди всичко, ако е възможно, уверете се, че работната ви директория е чиста, преди да опитате сливане, което може да доведе до конфликти.
 Ако имате текуща работа, опитайте да я къмитнете във временен клон или да я маскирате (stashing).
 Това ви гарантира, че ще можете да отмените *всичко*, което предстои да опитате.
-Ако имате незаписани промени в работната директория когато опитате сливане, някои от следващите действия могат да доведат до загубата им.
+Ако имате незаписани промени в работната директория когато опитате сливане, някои от следващите действия могат да ви помогнат да съхраните тази работа.
 
 Нека видим един прост пример.
 Имаме кратък Ruby файл, който отпечатва 'hello world'.

book/07-git-tools/sections/revision-selection.asc

@@ -60,7 +60,7 @@ a11bef0 first commit
 ----
 
 В общи линии, 8 до 10 символа са повече от достатъчни за гарантирана уникалност в рамките на един проект.
-Например, към октомври 2017, Linux ядрото (доста мащабен проект) има над 700 хиляди къмита и почти 6 милиона обекта, като не съществуват два такива с повтарящи се първи 11 символа в своя SHA-1 хеш.
+Например, към юни 2018, Linux ядрото (доста мащабен проект) има над 700 хиляди къмита и почти 6.5 милиона обекта, като не съществуват два такива с повтарящи се първи 11 символа в своя SHA-1 хеш.
 
 [NOTE]
 .КРАТКО УТОЧНЕНИЕ ЗА SHA-1
@@ -81,7 +81,7 @@ SHA-1 хеш сумата е с дължина 20 байта или 160 бита
 Това е 1200 пъти по-голямо число от броя песъчинки на земята.
 
 Ето пример, който дава идея за това какво е нужно да получите SHA-1 повторение.
-Ако всички 6.5 милиарда човека на земята програмираха, и всяка секунда всеки един от тях произвежда код еквивалентен на цялото Linux ядро (3.6 милиона Git обекта) и го изпраща в едно грамадно общо Git хранилище, биха били необходими около 2 години докато това хранилище получи толкова обекти, че да има 50% шанс от единично SHA-1 повторение.
+Ако всички 6.5 милиарда човека на земята програмираха, и всяка секунда всеки един от тях произвежда код еквивалентен на цялото Linux ядро (6.5 милиона Git обекта) и го изпраща в едно грамадно общо Git хранилище, биха били необходими около 2 години докато това хранилище получи толкова обекти, че да има 50% шанс от единично SHA-1 повторение.
 Така че, SHA-1 колизията е по-малко вероятна от това всеки член на екипа ви да бъде атакуван и убит от вълци в различно място в една и съща нощ.
 
 ====
@@ -120,7 +120,7 @@ ca82a6dff817ec66f44342007202690a93763949
 ----
 $ git reflog
 734713b HEAD@{0}: commit: fixed refs handling, added gc auto, updated
-d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' stategy.
+d921970 HEAD@{1}: merge phedders/rdocs: Merge made by the 'recursive' strategy.
 1c002dd HEAD@{2}: commit: added some blame and merge stuff
 1c36188 HEAD@{3}: rebase -i (squash): updating HEAD
 95df984 HEAD@{4}: commit: # This is a combination of two commits.
@@ -264,11 +264,11 @@ Date:   Fri Nov 7 13:47:59 2008 -0500
     ignore *.gem
 ----
 
-Това може да се напише и като `HEAD^^^`, резултатът ще е същия:
+Това може да се напише и като `HEAD~~~`, резултатът ще е същия:
 
 [source,console]
 ----
-$ git show HEAD^^^
+$ git show HEAD~~~
 commit 1c3618887afb5fbcbea25b7c013f4e2114448b8d
 Author: Tom Preston-Werner <[email protected]>
 Date:   Fri Nov 7 13:47:59 2008 -0500

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

@@ -8,7 +8,7 @@ Git осигурява полезни инструменти за търсене
 [[_git_grep]]
 ==== Git Grep
 
-Git идва с командата `grep`, позволяваща ви лесно да търсите по стринг или регулярен израз във всяко къмитнато дърво или в работната директория.
+Git идва с командата `grep`, позволяваща ви лесно да търсите по стринг или регулярен израз във всяко къмитнато дърво, в работната директория и дори в индексната област.
 За примерите, които следват ще търсим в сорс кода на самия Git.
 
 По подразбиране, `git grep` ще търси само във файловете от работната директория.

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

@@ -22,14 +22,14 @@ sub   2048R/874529A9 2014-06-04
 
 [source,console]
 ----
-gpg --gen-key
+$ gpg --gen-key
 ----
 
 След като веднъж имате частен ключ, можете да настроите Git да го използва за подпис на нещата ви посредством конфигурацията `user.signingkey`.
 
 [source,console]
 ----
-git config --global user.signingkey 0A46826A
+$ git config --global user.signingkey 0A46826A
 ----
 
 Сега Git по подразбиране ще използва този ключ за да подписва тагове и къмити, ако желаете това.

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

@@ -38,7 +38,8 @@ Git използва няколко environment променливи за да 
 *`GIT_CEILING_DIRECTORIES`* контролира маниера на търсене за `.git` директория.
 Ако посещавате директории, достъпа до които е бавен (например такива на лентово устройство или през бавна мрежова връзка), може да искате да инструктирате Git да спре да опитва по-рано отколкото би могъл.
 
-*`GIT_WORK_TREE`* е root локацията на работната директория за non-bare хранилище. Ако са указани --git-dir или GIT_DIR, но нито едно от --work-tree, GIT_WORK_TREE и core.worktree, тогава за текуща работна директория се счита най-горното ниво на работното ви дърво.
+*`GIT_WORK_TREE`* е root локацията на работната директория за non-bare хранилище. 
+Ако са указани `--git-dir` или `GIT_DIR`, но нито едно от `--work-tree`, `GIT_WORK_TREE` и `core.worktree`, тогава за текуща работна директория се счита най-горното ниво на работното ви дърво.
 
 *`GIT_INDEX_FILE`* е пътя до индексния файл (само за non-bare хранилища).