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

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

497 голосов
/ 26 декабря 2009

Какой смысл функции Sign Off в Git ? 

git commit --signoff

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

Ответы [ 4 ]

477 голосов
/ 26 декабря 2009

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

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

62 голосов
/ 26 декабря 2012

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

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

Add tests to statement printer.

Signed-off-by: Super Developer <super.dev@gmail.com>

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

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

Add tests to statement printer.

Signed-off-by: Super Developer <super.dev@gmail.com>

[uber.dev@gmail.com: Renamed test methods according to naming convention.]
Signed-off-by: Uber Developer <uber.dev@gmail.com>

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

28 голосов
/ 06 февраля 2016

git 2.7.1 (февраль 2016 г.) поясняет, что в commit b2c150d (05 января 2016 г.) от David A. Wheeler (david-a-wheeler) .
(Объединено с Junio ​​C Hamano - gitster - в коммит 7aae9ba , 05 февраля 2016 г.)

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

-s::
--signoff::

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

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

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

Это было вдохновлено " lwn article 'Bottomley: скромное предложение по DCO' " (Сертификат происхождения разработчика), где Пол отметил:

Проблема, с которой я столкнулся в 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 г.) по W. Тревор Кинг (wking) .
(Объединено Junio ​​C Hamano - gitster - в коммит fb4cd88 , 06 ноября 2017 г.)

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

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

14 голосов
/ 15 декабря 2016

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

Заголовки или трейлеры (↑ 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 <kernel@linuxace.com>
 Acked-by: Hugh Dickins <hughd@google.com>
 Reviewed-by: Michal Hocko <mhocko@suse.com>
 Cc: Andy Lutomirski <luto@kernel.org>
 Cc: Kees Cook <keescook@chromium.org>
 Cc: Oleg Nesterov <oleg@redhat.com>
 Cc: Willy Tarreau <w@1wt.eu>
 Cc: Nick Piggin <npiggin@gmail.com>
 Cc: Greg Thelen <gthelen@google.com>
 Cc: stable@vger.kernel.org
 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

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

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

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

См .: https://git.wiki.kernel.org/index.php/CommitMessageConventions

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

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

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

...