Jaki jest sens funkcji Wyloguj się w Git ?

git commit --signoff

Kiedy powinienem go użyć, jeśli w ogóle?

Wylogowanie się jest wymagane do uzyskania łatek do jądra Linuksa i kilku innych projektów, ale większość projektów tak naprawdę go nie używa.

Został wprowadzony w następstwie procesu SCO (i innych oskarżeń SCO o naruszenie praw autorskich , z których większość nigdy nie wniosła sprawy do sądu), jako świadectwo pochodzenia deweloperów . Mówi się, że poświadczasz, że utworzyłeś łatkę, o której mowa, lub że, zgodnie z Twoją najlepszą wiedzą, został on utworzony na podstawie odpowiedniej licencji typu open source lub że został Ci dostarczony przez kogoś jeszcze na tych warunkach. Może to pomóc w ustanowieniu łańcucha osób, które biorą odpowiedzialność za status praw autorskich danego kodu, aby zapewnić, że kod chroniony prawem autorskim, który nie został wydany na podstawie odpowiedniej licencji wolnego oprogramowania (open source), nie jest zawarty w jądrze.

Wylogowanie to wiersz na końcu komunikatu zatwierdzenia, który poświadcza, kto jest autorem zatwierdzenia. Jego głównym celem jest poprawa śledzenia tego, kto co zrobił, zwłaszcza z łatkami.

Przykład zatwierdzenia:

Add tests for the payment processor.

Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>

Powinien zawierać prawdziwą nazwę użytkownika, jeśli jest używany w projekcie typu open source.

Jeśli opiekun oddziału będzie musiał nieznacznie zmodyfikować łatki w celu ich scalenia, może poprosić zgłaszającego o ponowne wprowadzenie poprawek, ale przyniosłoby to efekt przeciwny do zamierzonego. Może dostosować kod i odłożyć swój podpis na końcu, aby pierwotny autor wciąż zyskał uznanie za łatkę.

Add tests for the payment processor.

Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>

[Project Maintainer: Renamed test methods according to naming convention.]
Signed-off-by: Project Maintainer <project.maintainer@example.com>

Źródło: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

git 2.7.1 (luty 2016 r.) wyjaśnia, że ​​w zatwierdzeniu b2c150d (05 stycznia 2016 r.) David A. Wheeler ( david-a-wheeler) .
^{(Połączone przez Junio ​​C Hamano - gitster- w commit 7aae9ba , 05 lutego 2016)}

git commitstrona man zawiera teraz:

-s::
--signoff::

Dodaj Signed-off-bywiersz przez osobę zatwierdzającą na końcu komunikatu dziennika zatwierdzeń.
Znaczenie podpisania zależy od projektu, ale zwykle poświadcza, że ​​zlecający ma prawo do przesłania tej pracy na tej samej licencji i wyraża zgodę na certyfikat pochodzenia dewelopera ( więcej informacji na stronie https://developercertificate.org ).

Rozwiń dokumentację opisującą --signoff

Zmodyfikuj różne pliki dokumentów (strony podręcznika), aby bardziej szczegółowo wyjaśnić, co --signoffto znaczy.

Inspiracją był „ artykuł z„ Bottomley: skromna propozycja w DCO ” ” (Developer Certificate of Origin), w którym Paul zauważył:

Problem mam z DCO jest to, że dodanie „ -s” argumentem do git commit naprawdę nie znaczy, że nawet słyszał o DCO ( strona człowiek nie wspomina o tym nigdzie DCO ), nie wspominając rzeczywiście widział.git commit

Jak więc obecność „ signed-off-by” w jakikolwiek sposób może sugerować, że nadawca zgadza się z DCO? W połączeniu z faktem widziałem odpowiedzi na listach do poprawek bez SOB, które mówią tylko „Wyślij to ponownie signed-off-by, abym mógł to zatwierdzić”.

Rozszerzenie dokumentacji gita ułatwi argumentowanie, że programiści rozumieli, --signoffkiedy z niego korzystają.

Zauważ, że to wylogowanie jest teraz (dla Git 2.15.x / 2.16, Q1 2018) również dostępne git pull.

Zobacz commit 3a4d2c7 (12 października 2017 r.) Autorstwa W. Trevora Kinga ( wking) .
^{(Połączone przez Junio ​​C Hamano - gitster- w commit fb4cd88 , 06 listopada 2017)}

pull: przejdź --signoff/--no-signoffdo „ git merge”

scalanie może zająć --signoff, ale bez przeciągania w --signoffdół jest niewygodne w użyciu; pozwól „ pull”, aby wziąć opcję i przejść przez nią.

Istnieje kilka fajnych odpowiedzi na to pytanie. Spróbuję dodać szerszą odpowiedź, a mianowicie o tym, jakie są tego rodzaju linie / nagłówki / przyczepy w obecnej praktyce. W szczególności nie tyle nagłówek podpisu (to nie jedyny).

Nagłówki lub zwiastuny (↑ 1), takie jak „sign-off” (↑ 2), są w obecnej praktyce w projektach takich jak Git i Linux, skutecznie ustrukturyzowane metadane dla zatwierdzenia. Wszystkie są dołączane na końcu komunikatu zatwierdzenia, po „swobodnej formie” (nieustrukturyzowanej) części treści komunikatu. Są to pary symbol-wartość (lub klucz-wartość ) zwykle rozdzielane dwukropkiem i spacją ( :␣).

Jak wspomniałem, „podpisanie się” nie jest jedynym zwiastunem w obecnej praktyce. Zobacz na przykład ten zatwierdzenie , które ma związek z „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>

Oprócz powyższego zwiastuna „Sign-off” dostępne są:

• „Cc” (powiadomiono o łatce)
• „Acked-by” (potwierdzony przez właściciela kodu, „wygląda mi dobrze”)
• „Oceniony przez” (zrecenzowany)
• „Zgłoszone i przetestowane przez” (zgłoszono i przetestowałem problem (zakładam))

Inne projekty, jak na przykład Gerrit, mają dla nich własne nagłówki i związane z nimi znaczenie.

Zobacz: https://git.wiki.kernel.org/index.php/CommitMessageConventions

Morał historii

Mam wrażenie, że chociaż początkową motywacją dla tych konkretnych metadanych były pewne kwestie prawne (sądząc po innych odpowiedziach), praktyka takich metadanych wykroczyła poza zwykłe zajmowanie się przypadkiem tworzenia łańcucha autorstwa.

[↑ 1]: man git-interpret-trailers
[↑ 2]: Wydaje się, że są one czasem nazywane „szlochem” (inicjały).