Qual è il Segno Spegnimento automatico in Git per?

Question

Qual è il punto di Segno Spegnimento automatico in Git?

git commit --signoff

Quando si dovrebbe utilizzare, se non del tutto?

Answer 1

Sign-off è un requisito per ottenere patch nel kernel Linux e un paio di altri progetti, ma la maggior parte dei progetti in realtà non lo uso.

E 'stato introdotto sulla scia della SCO querela , (e altre accuse di violazione del copyright da SCO , la maggior parte dei quali non hanno mai effettivamente preso in tribunale), come < a href = "http://developercertificate.org/" rel = "noreferrer"> Gli sviluppatori Certificato di origine . E 'usato per dire che Lei dichiara di aver creato la patch in questione, o che si certifica che al meglio delle tue conoscenze, è stato creato sotto una licenza open-source del caso, o che è stato fornito da qualcuno il resto sotto questi termini. Questo può aiutare a stabilire una catena di persone che prendono la responsabilità per lo status del copyright del codice in questione, per contribuire a garantire che il codice protetto da copyright non rilasciato sotto un software libero appropriato (open source) la licenza non è incluso nel kernel.

Answer 2

Sign-off è una linea alla fine del messaggio di commit che certifica che è l'autore del commit. Il suo scopo principale è quello di migliorare il tracciamento di chi ha fatto cosa, in particolare con le patch.

Esempio commit:

Add tests to statement printer.

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

Si deve contenere il nome utente reale se usato per un progetto open-source.

Se ramo manutentore bisogno di modificare leggermente le patch in modo da unirle, che potesse chiedere il mittente a Rediff, ma sarebbe controproducente. Si può regolare il codice e mettere il suo segno-off alla fine in modo l'autore ottiene ancora credito per la patch e non gli insetti introdotte.

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>

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

Answer 3

git 2.7.1 (febbraio 2016) chiarisce che commettere b2c150d (05 Gen 2016) da David A.Wheeler (david-a-wheeler).
^{(Fusa per Junio C Hamano -- gitster -- in commettere 7aae9ba, 05 Febbraio 2016)}

git commit pagina man ora comprende:

-s::
--signoff::

Aggiungere Signed-off-by linea con il committente al fine di commettere il messaggio di log.
Il significato di una chiusura dipende da progetto a progetto, ma in genere certifica che il committente ha il diritto di presentare questo lavoro sotto la stessa licenza e si impegna per uno Sviluppatore Certificato di Origine (vedere https://developercertificate.org per ulteriori informazioni).

---

Espandere la documentazione che descrive --signoff

Modifica di documenti diversi (man page) file di spiegare più in dettaglio cosa --signoff significa.

Questo è stato ispirato da "lwn articolo 'Bottomley:Una modesta proposta, il DCO'"(Sviluppatore Certificato di Origine) dove paulj notato:

Il problema che ho con il DCO è che c' l'aggiunta di un "-s"l'argomento a git commit in realtà non significa che si hanno anche sentito parlare del DCO (il git commit pagina man non fa alcuna menzione del DCO ovunque), mente mai realmente visto.

Così come la presenza di "signed-off-by"implica in alcun modo il mittente è l'accettazione e impegno per il DCO?Combinato con il fatto che ho visto le risposte sulle liste per le patch senza Singhiozzi che non dicono nulla di più di "rinvia con signed-off-by così posso commettere".

Estensione di git della documentazione di rendere più facile sostenere che gli sviluppatori capito --signoff quando lo utilizzano.

---

Nota che questa chiusura è ora (per Git 2.15.x/2.16, Q1 2018) disponibili per la git pull come bene.

Vedere commettere 3a4d2c7 (12 Ottobre 2017) da W.Trevor Re (wking).
^{(Fusa per Junio C Hamano -- gitster -- in commettere fb4cd88, 06 Nov 2017)}

pull:pass --signoff/--no-signoff per "git merge"

unione può prendere --signoff, ma senza tirare il passaggio --signoff in basso, è scomodo da usare;consenti"pull"per prendere l'opzione e passare attraverso.

Answer 4

Ci sono alcune belle risposte su questo argomento. Cercherò di aggiungere un altro risposta ampia, vale a dire su ciò che questi tipi di linee / header / rimorchi sono circa nella pratica corrente. Non tanto per il colpo di testa sign-off in particolare (non è l'unico).

intestazioni o rimorchi (↑ 1) come “segno-off” (↑ 2), in corrente pratica in progetti come Git e Linux, i metadati in modo efficace strutturato per il commit. Questi sono tutti aggiunti alla fine del messaggio di commit, dopo la “forma libera” (non strutturato) parte del corpo del messaggio. Questi sono token-value (o valore-chiave ) coppie tipicamente delimitata da una due punti e uno spazio (:␣).

Come ho già detto, “sign-off” non è l'unico rimorchio nella pratica corrente. Vedere per esempio questo commit , che ha a che fare con “Mucca sporca”:

 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 “sign-off” in quanto sopra, v'è:

• “CC” (è stata notificata sulla patch)
• “Acked-by” (riconosciuto dal proprietario del codice, “sembra buono per me”)
• “Inviato-by” (rivisto)
• “ha riferito e testato-by” (riferito e testato la questione (presumo))

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

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

Morale della storia

La mia impressione è che, anche se la motivazione iniziale per questo particolare dei metadati è stato alcuni problemi legali (a giudicare dalle altre risposte), la pratica di tali metadati ha progredito oltre la semplice trattare il caso di formare una catena di paternità.

[↑ 1]: man git-interpret-trailers
[↑ 2]: queste sono a volte chiamato anche “s-o-b” (iniziali), sembra

.