Для чего нужна функция выхода из системы в Git?

Question

Какой смысл в функции выхода из системы в Git?

git commit --signoff

Когда я должен использовать это, если вообще?

Answer 1

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

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

Answer 2

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

Пример коммита:

Add tests to statement printer.

Signed-off-by: Super Developer <[e-mail]>

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

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

Add tests to statement printer.

Signed-off-by: Super Developer <[e-mail]>

[[e-mail]: Renamed test methods according to naming convention.]
Signed-off-by: Uber Developer <[e-mail]>

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

Answer 3

В git 2.7.1 (февраль 2016 г.) поясняется, что в коммите b2c150d (05 января 2016 г.) Дэвид А. Уилер ( david-a-wheeler )
^{(Объединено Юнио С Хамано -} gitster ^{- в комм. 7aae9ba, 05 февраля 2016 г.)}

git commit Страница man теперь включает в себя:

-s::
--signoff::

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

---

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

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

Это было вдохновлено " lwn article" Bottomley: скромное предложение по DCO " (Developer Certificate of Origin), где Пол отметил:

Проблема с DCO заключается в том, что там добавляется -s "аргумент в пользу git commit не означает, что вы даже слышали о DCO (git commit Страница man нигде не упоминает о DCO), не говоря уже о том, чтобы увидеть это.

Так как же может присутствовать " signed-off-by "каким-либо образом подразумевается, что отправитель согласен с DCO и принимает на себя обязательство? В сочетании с тем, что я видел ответы в списках на исправления без SOB, в которых ничего не сказано, кроме как" Отправить это с signed-off-by так что я могу это совершить ".

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

---

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

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

pull: проходить --signoff/--no-signoff к " git merge "

слияние может занять --signoff, но без прохождения тяги --signoff вниз неудобно использовать; разрешать ' pull "принять вариант и передать его до конца.

Answer 4

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

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

Как я уже говорил, "выход" не единственный трейлер в современной практике. Посмотрите, например, этот коммит, который имеет отношение к "Грязной корове":

 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 <[e-mail]>
 Acked-by: Hugh Dickins <[e-mail]>
 Reviewed-by: Michal Hocko <[e-mail]>
 Cc: Andy Lutomirski <[e-mail]>
 Cc: Kees Cook <[e-mail]>
 Cc: Oleg Nesterov <[e-mail]>
 Cc: Willy Tarreau <[e-mail]>
 Cc: Nick Piggin <[e-mail]>
 Cc: Greg Thelen <[e-mail]>
 Cc: [e-mail]
 Signed-off-by: Linus Torvalds <[e-mail]>

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

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

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

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

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

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

[↑ 1]: man git-interpret-trailers
[↑ 2]: Кажется, их также иногда называют "рыданиями" (инициалы).