За какво е функцията за изключване в git?

Каква е точката на изходната функция в git ?

 git commit --signoff 

Кога трябва да го използвам, ако изобщо?

400
26 дек. Кларк Габел е на 26 декември 2009-12-26 01:30 '09 в 1:30 ч. 2009-12-26 01:30 часа
@ 4 отговора

Извличане е изискване за получаване на поправки в ядрото на Linux и няколко други проекта, но повечето проекти не го използват.

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

392
26 дек. Отговорът е даден от Брайън Кембъл 26 декември. 2009-12-26 01:39 '09 в 1:39 2009-12-26 01:39

Изходът е низът в края на съобщението за предаване, който идентифицира кой е авторът на фиксацията. Основната му цел е да подобри проследяването на това кой какво е направил, особено с корекции.

например:

 Made an update to xyz. Signed-off-by: Super Developer <super.dev@gmail.com> 

Трябва да съдържа истинско потребителско име, ако се използва за проект с отворен код.

border=0

Ако разработчик на клон трябва да промени малко кръпки, за да ги обедини, той може да поиска от подателя да повтори, но това ще бъде непродуктивно. Той може да коригира кода и да го сложи в края, така че авторът все още да получи заем за кръпка, а не за въведените грешки.

 Made an update to xyz. Signed-off-by: Super Developer <super.dev@gmail.com> [uber.dev@gmail.com: renamed methods according to naming conventions.] Signed-off-by: Uber Developer <uber.dev@gmail.com> 

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

45
26 дек. Hoto отговори на 26 декември 2012-12-26 20:36 '12 в 20:36 ч. 2012-12-26 20:36

git 2.7.1 (февруари 2016) обяснява, че в коммитирането b2c150d (5 януари 2016 г.) Дейвид А. Уилър ( david-a-wheeler ) .
(комбинирано от Junio ​​C gitster - gitster - в ангажимент 7aae9ba , 5 февруари 2016 г.

git commit страницата на човека за git commit сега включва:

 -s:: --signoff:: 

Добавете подписващия ред на изпращача до края на съобщението на дневника.
Сигналната стойност зависи от проекта, но обикновено потвърждава, че изпълнителят има право да изпрати тази работа под един лиценз и е съгласен със сертификата на разработчика на Origin (за повече информация вижте http://developercertificate.org/ ).


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

Променете различните документи (man pages), за да обясните по-подробно какво означава - --signoff .

Това беше вдъхновено от „ статията от лозата„ Bottomley: скромно предложение за DCO “ (Origin Developer Certificate), където Павел отбеляза,

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

И така, как присъствието на „ Signed-off-by “ по някакъв начин означава, че подателят се съгласява и предава СДК? Във връзка с това видях отговорите на списъците на пачовете без SOB, които казват не повече от "Изпрати го с помощта на Signed-off-by , за да мога да го направя."

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


Моля, обърнете внимание, че това съобщение сега (за git 2.15.x / 2.16, Q1 2018) е достъпно за git pull .

Вижте ангажимент 3a4d2c7 (12 октомври 2017 г.) У. Тревър Кинг ( wking ) .
(сливането на Junio ​​S gitster - gitster - в ангажимент fb4cd88 , ноември 06, 2017

pull : pass --signoff/--no-signoff на " git merge "

сливането може да отнеме - --signoff , но без да се издърпва - --signoff е да се използва; позволете „ pull “ да вземете опцията и да я предадете.

21
06 февр. Отговорът е даден VonC 06 Feb. 2016-02-06 09:22 '16 в 9:22 ч. 2016-02-06 09:22

Има някои добри отговори на този въпрос. Опитвам се да добавя още един широк отговор, а именно, какви са видовете линии / заглавия / ремаркета в съвременната практика. Не много в заглавието (това не е единственото).

Заглавките или ремаркетата () 1), като "изключване" () 2), в настоящата практика в проекти като Git и Linux, са ефективно структурирани метаданни за ангажиране. Всички те се добавят към края на съобщението за предаване, след "свободната форма" (неструктурирана) част от тялото на съобщението. Това са двойки :␣ (или ключова стойност), които обикновено са ограничени до двоеточие и интервал ( :␣ ).

Както споменах, "изключването" не е единственият трейлър в настоящата практика. Вижте например този ангажимент , който е свързан с "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 <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> 

В допълнение към ремаркето за отписване в примера по-горе има:

  • „Cc“ (бе уведомен за кръпка)
  • „Acked-by“ (потвърдено от собственика на кода, „изглежда добре за мен“)
  • „Проверени“ (гледани)
  • „Изпратено и удостоверено“ (съобщава се и е потвърден проблемът (предполагам))

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

Вижте: https://git.wiki.kernel.org/index.php/CommitMessageConventions

Морал на историята

Останах с впечатлението, че въпреки че първоначалната мотивация за тази конкретна метаданна е някакъв правен въпрос (съдейки по други отговори), практиката на подобни метаданни напредна в случая с формирането на авторската верига.

[] 1]: man git-interpret-trailers
[] 2]: Понякога те се наричат ​​и "плач" (инициали).

3
15 дек. Отговорът е даден от Guildenstern 15 декември. 2016-12-15 16:06 '16 в 16:06 2016-12-15 16:06

Други въпроси относно тагове или Ask a Question