Ответ 1

Выписка - это требование для получения исправлений в ядре Linux и нескольких других проектах, но большинство проектов на самом деле его не используют.

Это было введено после иск SCO, (и другие обвинения в нарушении авторских прав от ШОС, большинство из которых они никогда не принимали в суде), как Сертификат происхождения разработчиков. Он используется, чтобы сказать, что вы подтверждаете, что вы создали исправление, или что вы подтверждаете, что, насколько вам известно, оно было создано по соответствующей лицензии с открытым исходным кодом или что оно было предоставлено вам кем-то иначе под этими условиями. Это может помочь создать цепочку людей, которые берут на себя ответственность за статус авторского права на данный код, чтобы гарантировать, что авторский код, не выпущенный в соответствии с лицензией бесплатного программного обеспечения (с открытым исходным кодом), не будет включен в ядро.

Ответ 2

Вывод - это строка в конце сообщения фиксации, которая удостоверяет, кто является автором фиксации. Его основная цель - улучшить отслеживание того, кто что сделал, особенно с исправлениями.

Пример:

Made an update to xyz.

Signed-off-by: Super Developer <[email protected]>

Он должен содержать реальное имя пользователя, если он используется для проекта с открытым исходным кодом.

Если разработчику ветки нужно немного модифицировать патчи, чтобы слить их, он может попросить подателя повторить, но это будет контрпродуктивно. Он может скорректировать код и поместить его в конец, чтобы автор все еще получал кредит за патч, а не за введенные ошибки.

Made an update to xyz.

Signed-off-by: Super Developer <[email protected]>
[[email protected]: renamed methods according to naming conventions.]
Signed-off-by: Uber Developer <[email protected]>

Источник: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

Ответ 3

git 2.7.1 (февраль 2016 г.) поясняет, что в commit b2c150d (05 января 2016 г.) Дэвид А. Уилер (david-a-wheeler).
^{(объединено Junio ​​C Hamano - gitster - в commit 7aae9ba, 05 февраля 2016 г.}

git commit man page теперь включает в себя:

-s::
--signoff::

Добавьте строку Signed-off-by коммиттера в конце сообщения журнала фиксации.
Значение signoff зависит от проекта, но оно обычно подтверждает, что коммиттер имеет права отправить эту работу под одной лицензией и согласен с сертификатом разработчика Origin (см. http://developercertificate.org/ для получения дополнительной информации).

Развернуть документацию, описывающую --signoff

Измените различные документы (man-страницы), чтобы более подробно объяснить, что означает --signoff.

Это было вдохновлено "статья из лоза "Bottomley: скромное предложение по DCO" (сертификат разработчика Origin), где пауль отметил

Проблема с DCO заключается в том, что там добавление аргумента <<27 > к git commit не означает, что вы даже слышали о DCO (t22 > man не упоминает DCO в любом месте), неважно, что это вообще видели.

     

Итак, каким образом присутствие" Signed-off-by "каким-либо образом подразумевает, что отправитель соглашается и передает DCO? В сочетании с фактом я видел ответы на списки на патчи без SOB, которые говорят не более, чем" Отправить это с помощью Signed-off-by, чтобы я мог его совершить".

Расширение документации git упростит утверждение, что разработчики поняли --signoff, когда они его используют.

Обратите внимание, что это сообщение теперь (для git 2.15.x/2.16, Q1 2018) доступно для git pull.

См. commit 3a4d2c7 (12 октября 2017 г.) W. Тревор Кинг (wking).
^{(слияние Юнио С Хамано - gitster - в commit fb4cd88, 06 ноября 2017 г.}

pull: передать --signoff/--no-signoff в "git merge"

merge может принимать --signoff, но без вытягивания --signoff вниз, это неудобно использовать; разрешить 'pull' взять опцию и передать ее через.

Ответ 4

Есть несколько хороших ответов на этот вопрос. Я пытаюсь добавить еще широкий ответ, а именно о том, что такое виды линий/заголовков/трейлеров в современной практике. Не так много в заголовке (его не единственный).

Заголовки или трейлеры (↑ 1), такие как "выключение" (↑ 2), в текущем практика в таких проектах, как Git и Linux, эффективно структурированные метаданные для фиксации. Все они добавлены в конец сообщения фиксации, после "свободной формы" (неструктурированной) части тела сообщения. Это пары токенов (или ключ-значение), которые обычно ограничены двоеточие и пробел (:␣).

Как я уже упоминал, "выключение" - не единственный трейлер в текущей практике. Видеть например this commit, который связан с "Dirty Cow":

 mm: remove gup_flags FOLL_WRITE games from __get_user_pages()
 This is an ancient bug that was actually attempted to be fixed once
 (badly) by me eleven years ago in commit 4ceb5db9757a ("Fix
 get_user_pages() race for write access") but that was then undone due to
 problems on s390 by commit f33ea7f404e5 ("fix get_user_pages bug").

 In the meantime, the s390 situation has long been fixed, and we can now
 fix it by checking the pte_dirty() bit properly (and do it better).  The
 s390 dirty bit was implemented in abf09bed3cce ("s390/mm: implement
 software dirty bits") which made it into v3.9.  Earlier kernels will
 have to look at the page state itself.

 Also, the VM has become more scalable, and what used a purely
 theoretical race back then has become easier to trigger.

 To fix it, we introduce a new internal FOLL_COW flag to mark the "yes,
 we already did a COW" rather than play racy games with FOLL_WRITE that
 is very fundamental, and then use the pte dirty flag to validate that
 the FOLL_COW flag is still valid.

 Reported-and-tested-by: Phil "not Paul" Oester <[email protected]>
 Acked-by: Hugh Dickins <[email protected]>
 Reviewed-by: Michal Hocko <[email protected]>
 Cc: Andy Lutomirski <[email protected]>
 Cc: Kees Cook <[email protected]>
 Cc: Oleg Nesterov <[email protected]>
 Cc: Willy Tarreau <[email protected]>
 Cc: Nick Piggin <[email protected]>
 Cc: Greg Thelen <[email protected]>
 Cc: [email protected]
 Signed-off-by: Linus Torvalds <[email protected]>

В дополнение к трейлеру "sign-off" в приведенном выше примере есть:

• "Cc" (был уведомлен о патче)
• "Acked-by" (подтвержденный владельцем кода, "выглядит хорошо для меня" )
• "Проверено" (просмотрено)
• "Отправлено и проверено" (сообщается и проверяется проблема (я полагаю))

Другие проекты, такие как, например, Gerrit, имеют свои собственные заголовки и связанный с ними смысл.

Смотрите: https://git.wiki.kernel.org/index.php/CommitMessageConventions

Мораль истории

У меня сложилось впечатление, что хотя первоначальная мотивация для этого конкретными метаданными были некоторые юридические вопросы (судя по другой ответы), практика таких метаданных прогрессировала касающийся случая формирования авторской цепочки.

[↑ 1]: man git-interpret-trailers
[↑ 2]: Они также иногда называются "s-o-b" (инициалы).