Ниже приводятся некоторые рекомендации для того, чтобы созданная вами заплата была принята.
19.2.1.1. Отправляйте заплаты, а не целые архивы или файлы
Если изменения включают в себя новый файл, который отсутствует в коде, то, естественно, приходится отправлять данный файл целиком. Однако если изменяются только уже существующие файлы, отправлять их полностью не следует. Вместо этого следует отправить diff-файл, а именно вывод команды diff(1), выполненной для сравнения основной распространяемой версии с модифицированной.
Команда diff(1) и обратная ей команда patch(1) являются основными инструментами разработки открытого исходного кода. Diff-файлы лучше, чем целые файлы, поскольку разработчик, которому отсылается заплата, мог изменить основной код с момента получения копии создателем заплаты. Отправляя разработчику diff-файл, создатель заплаты предотвращает дополнительную работу по разделению изменений, которую придется выполнить разработчику, и демонстрирует таким образом, что он ценит его время.
19.2.1.2. Отправляйте исправления к текущей версии кода
Не стоит отправлять куратору заплаты к коду, который существовал за несколько версий до этого, и ожидать, что он сделает всю работу по определению того, какие исправления дублируются с изменениями, уже внесенными им самим, а какие действительно являются новыми.
Ответственность за отслеживание состояния исходного кода и отправку куратору минимальных заплат, которые выражают то, что их создатель хочет изменить в основном коде главной линии разработки, лежит на самом создателе заплаты. Это означает отправку исправлений к текущей версии.
19.2.1.3. Не следует включать заплаты для генерируемых файлов
Прежде чем отправить заплату, необходимо просмотреть ее и удалить все диапазоны кода, предназначенные для файлов, которые должны генерироваться автоматически после применения куратором исправлений и перекомпиляции программы. Классическим примером данной ошибки являются C-файлы, сгенерированные инструментами Bison или Flex.
В настоящее время наиболее распространенной разновидностью данной ошибки является отправка diff-файлов с большим диапазоном, который не содержит ничего, кроме отличий между сценариями configure создателя заплаты и куратора. Такой файл создается с помощью autoconf.
Такой подход является необдуманным и означает, что получатель будет вынужден отделять действительное содержание заплаты от большого количества шума. Данная ошибка незначительна, она не настолько важна, как некоторые из рассматриваемых далее, однако она не делает чести создателю заплаты.
19.2.1.4. Не отправляйте заплат, которые только убирают $-идентификаторы систем RCS или SCCS
Некоторые разработчики вносят специальные метки в свои исходные файлы, распространяемые с помощью системы контроля версий, когда возвращают отредактированные файлы, например, конструкции $Id$, используемые в системах RCS и CVS.
Если используется локальная система контроля версий, то изменения могут модифицировать данные метки. Это не представляет реальной опасности, поскольку когда получатель снова зарегистрирует исправленный код после применения заплаты, метки будут переназначены снова в соответствии с состоянием системы контроля версий куратора. Однако такие диапазоны исправлений являются излишними и отвлекают внимание. Лучше их не отправлять.
Данная ошибка также является незначительной, и вас простят, если более важные изменения сделаны верно, однако ее следует в любом случае избегать.
19.2.1.5. Используйте вместо формата по умолчанию (-e) форматы -с или -u
Принятый по умолчанию в diff(1) формат -е является крайне ненадежным. Он не включает в себя контекст, поэтому утилита patch не может справиться со своей задачей, если какие-либо строки были вставлены в код главной линии проекта или удалены с момента получения создателем заплаты своей копии кода.