Merge pull request #405 from SergeiKuznetsov/sha

Исправить написание слова SHA-1-хеш

Author: Morganov

book/07-git-tools/sections/rewriting-history.asc

@@ -399,4 +399,4 @@ $ git filter-branch --commit-filter '
 ----
 
 Эта команда пройдёт по всем коммитам и установит в них ваш новый адрес.
-Так как коммиты содержат значения SHA-1 хешей их родителей, эта команда изменяет SHA-1 хеш каждого коммита в вашей истории, а не только тех, которые соответствовали адресам электронной почты.
+Так как коммиты содержат значения SHA-1-хешей их родителей, эта команда изменяет хеш SHA-1 каждого коммита в вашей истории, а не только тех, которые соответствовали адресам электронной почты.

book/08-customizing-git/sections/attributes.asc

@@ -161,9 +161,9 @@ index 88839c4..4afcb7c 100644
 Однако, вы можете добавить текст в файл после извлечения и убрать его перед добавлением файла в коммит.
 Атрибуты Git позволяют это сделать двумя способами.
 
-Для начала, вы можете автоматически добавлять SHA-1 хэш объекта в поле `$Id$`.
-Если установить этот атрибут для одного или нескольких файлов, то каждый раз при извлечении ветки Git будет заменять это поле на SHA-1 хэш объекта.
-Важно заметить, что это SHA-1 хэш не коммита, а самого объекта.
+Для начала, вы можете автоматически добавлять SHA-1-хеш объекта в поле `$Id$`.
+Если установить этот атрибут для одного или нескольких файлов, то каждый раз при извлечении ветки Git будет заменять это поле на SHA-1-хеш объекта.
+Важно заметить, что это SHA-1-хеш не коммита, а самого объекта.
 Добавьте следующую строку в ваш файл `.gitattributes`:
 
 [source,ini]
@@ -178,7 +178,7 @@ index 88839c4..4afcb7c 100644
 $ echo '$Id$' > test.txt
 ----
 
-При последующих извлечениях Git будет добавлять SHA-1 хэш объекта:
+При последующих извлечениях Git будет добавлять SHA-1-хеш объекта:
 
 [source,console]
 ----
@@ -189,7 +189,7 @@ $Id: 42812b7653c7b88933f8a9d6cad0ca16714b9bb3 $
 ----
 
 Однако, этот результат имеет ограниченное применение.
-Если вы использовали подстановку ключевых слов в CVS или Subversion, то вы могли включать метку времени, а SHA-1 хэш не так полезен, потому что вы не можете сказать какой из двух хэшей старше, а какой новее просто взглянув на них.
+Если вы использовали подстановку ключевых слов в CVS или Subversion, то вы могли включать метку времени, а SHA-1-хеш не так полезен, потому что вы не можете сказать какой из двух хешей старше, а какой новее просто взглянув на них.
 
 Оказывается, вы можете написать свои фильтры для выполнения подстановок в файлах в момент коммита/извлечения.
 Эти фильтры называются «clean» и «smudge».

book/08-customizing-git/sections/config.asc

@@ -470,7 +470,7 @@ $ git apply --whitespace=fix <patch>
 
 ===== `receive.fsckObjects`
 
-Git способен убедиться, что каждый объект, отправленный командой `push`, валиден и соответствует своему SHA-1 хэшу.
+Git способен убедиться, что каждый объект, отправленный командой `push`, валиден и соответствует своему SHA-1-хешу.
 По умолчанию эта функция отключена; это очень дорогая операция и может привести к существенному замедлению, особенно для больших объёмов отправляемых данных или для больших репозиториев.
 Вы можете включить проверку целостности объектов для каждой операции отправки, установив значение `receive.fsckObjects` в `true`:
 

book/08-customizing-git/sections/hooks.asc

@@ -41,7 +41,7 @@
 
 Хук `prepare-commit-msg` запускается до вызова редактора сообщения коммита, но после создания стандартного сообщения.
 Это позволяет вам изменить стандартное сообщение коммита до того, как автор коммита увидит его.
-Хук принимает несколько параметров: путь к файлу, содержащему сообщение коммита, тип коммита и SHA-1 хэш, если текущий коммит является исправлением существующего.
+Хук принимает несколько параметров: путь к файлу, содержащему сообщение коммита, тип коммита и SHA-1-хеш, если текущий коммит является исправлением существующего.
 Для обычных коммитов этот хук бесполезен, однако находит своё применение для коммитов, где сообщение генерируется автоматически, например, для сообщений на основе шаблонов, коммитов слияния, сжимаемых и исправляемых коммитов.
 Его можно использовать для программного заполнения шаблона коммита необходимой информацией.
 
@@ -115,7 +115,7 @@ Pre-хуки могут возвращать ненулевой код в люб
 
 Хук `update` очень похож на `pre-receive`, за исключением того, что он выполняется для каждой ветки, которую отправитель пытается обновить.
 Если отправитель пытается отправить изменения в несколько веток, то `pre-receive` хук будет вызван однократно, а `update` выполнен для каждой изменяемой ветки.
-Вместо чтения из `stdin`, хук принимает три аргумента: название ссылки (ветка), SHA-1 хэш, на который указывала ссылка до отправки, и SHA-1 хэш коммита, отправляемого пользователем.
+Вместо чтения из `stdin`, хук принимает три аргумента: название ссылки (ветка), SHA-1-хеш, на который указывала ссылка до отправки, и SHA-1-хеш коммита, отправляемого пользователем.
 Если скрипт завершается ненулевым кодом, то отклоняются все изменения только для текущей ветки, при этом изменения для других веток всё ещё могут быть применены.
 
 ===== `post-receive`
@@ -124,3 +124,8 @@ Pre-хуки могут возвращать ненулевой код в люб
 Он принимает на `stdin` те же данные, что и хук `pre-receive`.
 Использовать его можно, например, для e-mail рассылки, для уведомления сервера непрерывной интеграции или обновления системы управления задачами -- разобрав сообщение коммита, можно определить необходимость создания, изменения или закрытия каких либо задач.
 Этот хук не может прервать процесс, но клиент остаётся подключённым пока он не завершится, поэтому избегайте выполнения длительных операций.
+
+[TIP]
+====
+Если вы пишете сценарий/хук, который другие должны будут прочитать, используйте длинные версии параметров командной строки; через шесть месяцев вы будете нас благодарить.
+====