Qual è il punto della funzione di disconnessione in Git ?

git commit --signoff

Quando dovrei usarlo, se non del tutto?

La firma è un requisito per ottenere patch nel kernel di Linux e in alcuni altri progetti, ma la maggior parte dei progetti non lo utilizza effettivamente.

È stato introdotto sulla scia della causa SCO (e altre accuse di violazione del copyright da parte di SCO , la maggior parte delle quali non ha mai portato in tribunale), come certificato di origine degli sviluppatori . Viene utilizzato per affermare che si certifica di aver creato la patch in questione, o che si certifica che, per quanto a sua conoscenza, è stata creata con una licenza open source appropriata o che è stata fornita da qualcuno altro in quei termini. Questo può aiutare a stabilire una catena di persone che si assumono la responsabilità dello stato del copyright del codice in questione, per garantire che il codice protetto da copyright non rilasciato sotto un'appropriata licenza di software libero (open source) non sia incluso nel kernel.

La firma è una riga alla fine del messaggio di commit che certifica chi è l'autore del commit. Il suo scopo principale è migliorare il tracciamento di chi ha fatto cosa, specialmente con le patch.

Esempio di commit:

Add tests for the payment processor.

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

Dovrebbe contenere il nome reale dell'utente se utilizzato per un progetto open source.

Se il manutentore del ramo ha bisogno di modificare leggermente le patch per unirle, potrebbe chiedere al redattore di rediffire, ma sarebbe controproducente. Può modificare il codice e mettere la firma alla fine in modo che l'autore originale ottenga ancora credito per la patch.

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>

Fonte: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html

git 2.7.1 (febbraio 2016) chiarisce che in commit b2c150d (05 gen 2016) di David A. Wheeler ( david-a-wheeler) .
^{(Unito da Junio ​​C Hamano - gitster- in commit 7aae9ba , 05 feb 2016)}

git commitla pagina man ora include:

-s::
--signoff::

Aggiungi Signed-off-byriga dal committer alla fine del messaggio di registro di commit.
Il significato di una firma dipende dal progetto, ma in genere certifica che il committer ha i diritti di presentare quest'opera con la stessa licenza e accetta un certificato di origine per sviluppatori (vedere https://developercertificate.org per ulteriori informazioni).

Espandi la descrizione della documentazione --signoff

Modifica vari file di documenti (pagina man) per spiegare in modo più dettagliato cosa --signoffsignifica.

Questo è stato ispirato dall '" articolo lwn' Bottomley: una modesta proposta sul DCO " (Certificato di origine per sviluppatori) in cui Paul notava:

Il problema che ho con DCO è che l' aggiunta di un " -s" argomento a git commit non significa davvero che tu abbia mai sentito parlare del DCO ( la git commitpagina man non fa menzione del DCO da nessuna parte ), non importa davvero vederlo.

Quindi, come può la presenza di " signed-off-by" implicare in qualche modo che il mittente accetta e si impegna con il DCO? In combinazione con il fatto, ho visto le risposte sugli elenchi alle patch senza SOB che non dicono altro che "Rinvia questo con signed-off-bycosì posso commetterlo".

L'estensione della documentazione di git renderà più facile sostenere che gli sviluppatori --signoffabbiano capito quando la usano.

Nota che questo signoff è ora disponibile (anche per Git 2.15.x / 2.16, Q1 2018) git pull.

Vedi commit 3a4d2c7 (12 ott 2017) di W. Trevor King ( wking) .
^{(Unita da Junio ​​C Hamano - gitster- in commit fb4cd88 , 06 nov 2017)}

pull: passa --signoff/--no-signoffa " git merge"

l'unione può richiedere --signoff, ma senza trascinare --signoffverso il basso, è scomodo da usare; consenti ' pull' di prendere l'opzione e passarla attraverso.

Ci sono alcune belle risposte a questa domanda. Proverò ad aggiungere una risposta più ampia, vale a dire di cosa trattano questi tipi di linee / intestazioni / rimorchi nella pratica attuale. Non tanto sull'intestazione della firma in particolare (non è l'unica).

Header o trailer (↑ 1) come "sign-off" (↑ 2) sono, nella pratica corrente in progetti come Git e Linux, metadati strutturati in modo efficace per il commit. Questi sono tutti aggiunti alla fine del messaggio di commit, dopo la parte "forma libera" (non strutturata) del corpo del messaggio. Queste sono coppie token-valore (o chiave-valore ) in genere delimitate da due punti e uno spazio ( :␣).

Come ho già detto, il "sign-off" non è l'unico trailer nella pratica attuale. Vedi ad esempio questo commit , che ha a che fare con "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>

Oltre al trailer di "firma" di cui sopra, c'è:

• "Cc" (è stato informato della patch)
• "Acked-by" (riconosciuto dal proprietario del codice, "mi sta bene")
• “Review-by” (recensione)
• "Segnalato e testato da" (segnalato e testato il problema (presumo))

Altri progetti, come ad esempio Gerrit, hanno le loro intestazioni e il significato associato per loro.

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

Morale della storia

La mia impressione è che, sebbene la motivazione iniziale per questi particolari metadati fosse di natura giuridica (a giudicare dalle altre risposte), la pratica di tali metadati è andata oltre il solo caso di formare una catena di autori.

[↑ 1]: man git-interpret-trailers
[↑ 2]: a volte sono anche chiamati "singhiozzo" (iniziali).