Permalink
Browse files

ru/drawbacks.txt editing finished

  • Loading branch information...
1 parent c582092 commit da8dbc0cf0a489ec26e0d4776a45d29fbf6b2672 @t-t t-t committed Jul 3, 2010
Showing with 24 additions and 35 deletions.
  1. +3 −18 en/drawbacks.txt
  2. +21 −17 ru/drawbacks.txt
View
@@ -86,27 +86,12 @@ Git would benefit from defining the zero commit: as soon as a repository is cons
Then running git log, for example, would inform the user that no commits have been made yet, instead of exiting with a fatal error. Similarly for other tools.
-Every initial commit is implicitly a descendant of this zero commit. For example, rebasing an unrelated branch would cause the whole branch to be grafted on to the target. Currently, all but the initial commit is applied, resulting in a merge conflict. One workaround is to use `git checkout` followed by `git commit -C` on the initial commit, then rebase the rest.
+Every initial commit is implicitly a descendant of this zero commit.
-There are worse cases unfortunately. If several branches with different initial commits are merged together, then rebasing the result requires substantial manual intervention.
+However there are some problem cases unfortunately. If several branches with different initial commits are merged together, then rebasing the result requires substantial manual intervention.
=== Interface Quirks ===
-For commits A, B, the meaning of the expressions "A..B" and "A...B" depends
+For commits A and B, the meaning of the expressions "A..B" and "A...B" depends
on whether the command expects two endpoints or a range. See *git help diff*
and *git help rev-parse*.
-
-Some error messages are inscrutable. For example, if Git cannot create the
-lockfile +packed-refs.lock+, then you might see:
-
- $ git branch -D foo
- error: cannot delete 'refs/heads/foo' from packed refs
- error: Error deleting branch 'foo'
-
-This could happen if say filesystem trouble prevented the lockfile from being
-deleted in a previous Git command. In this case the solution is to delete the
-lockfile and try again, after ensuring no Git commands are still running.
-
-The push command ignores the state of the working directory of the target
-repository. To prevent confusion, push only into bare repositories, or setup a
-dedicated push-only branch.
View
@@ -46,42 +46,46 @@ Git на Microsoft Windows может быть громоздким:
=== Изменчивые Проекты ===
-Git была написан, чтобы быть быстрым по отношению к небольшим изменениям. Люди делают небольшие исправления от версии к версии. Однострочные исправление здесь, новые функции там, исправленные комментарии, и так далее. Но если ваши файлы, радикально отличаются в следующей ревизии, то на каждой фиксации, ваша история обязательно увеличивается на размер всего вашего проекта.
+Git была написан, чтобы быть быстрым по отношению к небольшим изменениям. Люди вносят небольшие правки от версии к версии. Однострочные исправление ошибки здесь, новая функция там, исправленные комментарии, и т.п. Но если ваши файлы, радикально различаются в соседних ревизиях, то с каждым коммитом ваша история неизбежно увеличится на размер всего проекта.
-Не существует системы управления версиями, которая может решить эту проблему, но пользователи Git пострадают больше, поскольку клонируется вся история.
+Никакая система контроля версий ничего не может с этим сделать, но пользователи Git страдают больше, поскольку обычно истории клонируются.
-Причины, почему эти изменения бывают настолько велики, должны быть изучены. Возможно, формат файла должен быть изменен. Малые изменения должны быть причиной малых изменений в самих файлах.
+Причины, по которым эти изменения столь велики, должны быть изучены. Возможно, надо изменить форматы файлов. Небольшие правки должны приводить к небольшим изменений не более чем в нескольких файлах.
-Или, возможно, то, что вам было нужно, это базы данных или система резервного копирования или архивы, а не система контроля версий. Например, контроль версий может быть плохо приспособлен для управления фотографиями периодически получаемых с веб-камеры.
+Возможно, вам была нужна база данных или система резервного/архивного копирования, а не система контроля версий. Например, контроль версий может быть плохо приспособлен для управления фотографиями периодически получаемых с веб-камеры.
-Если файлы действительно должны постоянно изменяться, и они действительно должно быть версионироваться, возможность использовать Git централизованным образом. Можно создать мелкой клоны, с небольшой или без истории проекта. Конечно, многие инструменты Git будут недоступны, и исправления должны быть представлены в виде патчей. Вероятно, это штраф, потому как неясно, почему кто-то хочет вести историю дико неустойчиво файлов.
+Если файлы действительно должны постоянно изменяться и при этом версионироваться, может иметь смысл использовать Git централизованным образом. Можно создать мелкие клоны, с небольшой историей или без истории вообще. Конечно, многие инструменты Git будут недоступны, и исправления придётся представлять в виде патчей. Возможно, это и хорошо, т.к. неясно, зачем кому-либо понадобится история крайне нестабильных файлов.
-Другим примером является проект, зависимый от прошивки, которая принимает форму огромного бинарного файла. История этой микропрограммы неинтересна для пользователей, и обновления сжимаются плохо, так версии микропрограммы могут излишне увеличить размера хранилища.
+Другой пример — это проект, зависимый от прошивки, принимающей форму огромного двоичного файла. Её история неинтересна пользователям, а обновления плохо сжимаются, потому ревизии прошивки могут неоправдано раздуть размер хранилища.
-В этом случае исходный код должен храниться в хранилище Git, а бинарные файлы - отдельно. Чтобы сделать жизнь проще, можно было бы распространять скрипт, который используется Git чтобы клонировать код и Rsync или мелкий клон Git для прошивки.
+В этом случае исходный код стоит держать в хранилище Git, а бинарные файлы отдельно. Для упрощения жизни можно распространять скрипт, использующий Git клонирования кода и rsync или мелкий клон Git для прошивки.
=== Глобальный счетчик ===
-Некоторые централизованные системы контроля версий, используют положительные числа, которые возрастают, когда происходит новый коммит. Git идентифицирует изменения их хэшем, который лучше во многих обстоятельствах.
+Некоторые централизованные системы контроля версий натуральное число, увеличивающееся при поступлении новыого коммита. Git идентифицирует изменения по их хешам, что лучше во многих обстоятельствах.
-Но некоторым люди нравится эти целые вокруг. К счастью, легко написать сценарии, чтобы при каждом обновлении центральное хранилище Git увеличивало целое число, возможно, в теге, и связывает его с хэшем последним коммитом.
+Но некоторым людям нравятся эти целые числа повсюду. К счастью, легко написать такой скрипт, чтобы при каждом обновлении центральное хранилище Git увеличивало целое число, возможно, в теге, и связывало его с хешем последнего коммита.
-Каждай клон может поддерживать такой счетчик, но это, вероятно, будет бесполезным, поскольку только центральное хранилище имеет значение для всех.
+Каждай клон может поддерживать такой счетчик, но это, видимо, будет бесполезным, поскольку только центральное хранилище и его счётчик имеет значение для всех.
=== Пустые подкаталоги ===
-Пустые подкаталоги не могут быть отслежены. Создайте пустой файл, чтобы обойти эту проблему.
+Пустые подкаталоги не могут отслеживаться. Создавайте подставные файлы, чтобы обойти эту проблему.
-В этом виноват не дизайн Git, а его текущая реализация. Если повезет и пользователи Git уделят больше внимания этой функции, возможно она будет реализована.
+В этом виноват не дизайн Git, а его текущая реализация. Если повезет и пользователи Git будут поднимать больше шума вокруг этой функции, возможно она будет реализована.
=== Первоначальный коммит ===
-Обычный ученый в области информатики считает от 0, а не от 1. К сожалению, Git с его коммитами не присоединиться к этой конвенции. Многие команды плохо работают до первого коммита. Кроме того, некоторые частные случаи должны быть обработаны специально, такие, как rebase веток с различными начальными коммитами.
+Шаблонный компьютерщик считает с 0, а не с 1. К сожалению, в отношении коммитов Git не придерживается этого соглашения. Многие команды недружелюбны до первоначального коммита. Кроме того, некоторые частные случаи требуют специальной обработки, к примеру rebase ветки с другим начальным коммитом.
-Git'у желательно определение нулевого совершения: как только будет построено хранилище, HEAD будет установлен в строку, состоящую из 20 нулевых байтов. Эта специальный коммит представляет собой пустое дерево, без родителей, предшествовавшие всему в хранилище Git.
+Git'у было бы выгодно определить нулевой коммит: чтобы сразу после создания хранилища, HEAD был установлен в строку, состоящую из 20 нулевых байтов. Этот специальный коммит представлял бы собой пустое дерево, без родителей, которое предшествует каждому хранилищу Git.
-Затем запустить *git log*, например, будет показывать пользователю, что коммиты еще не были сделаны вместо выхода с фатальной ошибкой. Аналогично для других инструментов.
+Тогда запуск *git log*, например, показывал бы пользователю, что коммиты ещё не были сделаны, вместо того чтобы завершаться с фатальной ошибкой. Аналогично для других инструментов.
-Каждая первоначальная фиксация - неявный потомок этого нулевого коммита. Например, несвязанный с какой-либо веткой rebase в целом будет привита на эту цель. В настоящее время применяются все, кроме первоначального коммита, в результате чего получается конфликт слияния. Один из способов заключается в использовании `git checkout` после `git commit -C` первоначального коммита, тогда rebase пройдет нормально.
+Каждый первоначальный коммит — неявный потомок этого нулевого коммита.
-К сожалению, в худшем случае, если несколько ветвей с различными начальными коммитами сливаются, то rebase результата требует значительного ручного вмешательства.
+Однако здесь, к сожалению, есть некоторые проблемные случаи. Если несколько ветвей с различными начальными коммитами сливаются, то rebase результата требует значительного ручного вмешательства.
+
+=== Причуды интерфейса ===
+
+Для коммитов А и Б значения выражений «А..Б» и «А...Б» зависят от того, ожидает ли команда указания двух конечных точек или промежутка. См. *git help diff* и *git help rev-parse*.

0 comments on commit da8dbc0

Please sign in to comment.