Quel est l'intérêt de la fonctionnalité de déconnexion dans Git ?
git commit --signoff
Quand dois-je l'utiliser, le cas échéant?
Quel est l'intérêt de la fonctionnalité de déconnexion dans Git ?
git commit --signoff
Quand dois-je l'utiliser, le cas échéant?
Réponses:
La déconnexion est une condition requise pour obtenir des correctifs dans le noyau Linux et quelques autres projets, mais la plupart des projets ne l'utilisent pas réellement.
Il a été introduit à la suite du procès de SCO (et d' autres accusations de violation du droit d'auteur de SCO , dont la plupart n'ont jamais été portées devant les tribunaux), en tant que certificat d'origine des développeurs . Il est utilisé pour dire que vous certifiez que vous avez créé le patch en question, ou que vous certifiez qu'à votre connaissance, il a été créé sous une licence open source appropriée, ou qu'il vous a été fourni par quelqu'un autrement dans ces conditions. Cela peut aider à établir une chaîne de personnes qui prennent la responsabilité du statut de copyright du code en question, pour aider à garantir que le code protégé par le droit d'auteur non publié sous une licence de logiciel libre (open source) appropriée n'est pas inclus dans le noyau.
La signature est une ligne à la fin du message de validation qui certifie qui est l'auteur de la validation. Son objectif principal est d'améliorer le suivi de qui a fait quoi, en particulier avec les correctifs.
Exemple de validation:
Add tests for the payment processor.
Signed-off-by: Humpty Dumpty <humpty.dumpty@example.com>
Il doit contenir le nom réel de l'utilisateur s'il est utilisé pour un projet open-source.
Si le responsable de succursale devait modifier légèrement les correctifs afin de les fusionner, il pourrait demander à l'émetteur de rediffuser, mais ce serait contre-productif. Il peut ajuster le code et mettre sa signature à la fin afin que l'auteur original obtienne toujours le crédit pour le 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>
Source: http://gerrit.googlecode.com/svn/documentation/2.0/user-signedoffby.html
authorchamp d'un git commit? J'ai toujours pensé que ce pourquoi il y avait un indépendant authoret le committerterrain. L'auteur étant l'auteur du correctif et le committer étant le gars qui a appliqué et poussé le correctif.
git 2.7.1 (février 2016) précise que dans commit b2c150d (05 janvier 2016) par David A. Wheeler ( david-a-wheeler) .
(Fusionné par Junio C Hamano - gitster- en commit 7aae9ba , 05 févr.2016 )
git commitla page de manuel comprend désormais:
-s::
--signoff::
Ajoutez une
Signed-off-byligne par le committer à la fin du message du journal de validation.
La signification d'une approbation dépend du projet, mais elle certifie généralement que le committer a le droit de soumettre ce travail sous la même licence et accepte un certificat d'origine de développeur (voir https://developercertificate.org pour plus d'informations).
Développer la documentation décrivant
--signoffModifier divers fichiers de document (page de manuel) pour expliquer plus en détail ce
--signoffsignifie.Cela a été inspiré par " lwn article 'Bottomley: A modest proposition on the DCO' " (Developer Certificate of Origin) où paulj a noté:
Le problème que j'ai avec DCO est que l' ajout d'un
-sargument " " pour git commit ne signifie pas vraiment que vous avez même entendu parler du DCO ( lagit commitpage de manuel ne fait aucune mention du DCO n'importe où ), sans même le voir.Alors, comment la présence de "
signed-off-by" peut-elle impliquer d'une manière ou d'une autre que l'expéditeur accepte et s'engage auprès de l'ACD? Combiné avec le fait, j'ai vu des réponses sur des listes de correctifs sans SOB qui ne disent rien de plus que "Renvoyez cela avecsigned-off-bypour que je puisse le valider".L'extension de la documentation de git facilitera l'argument selon lequel les développeurs ont compris
--signoffquand ils l'utilisent.
Notez que cette approbation est désormais disponible (pour Git 2.15.x / 2.16, Q1 2018) git pull.
Voir commit 3a4d2c7 (12 octobre 2017) de W.Trevor King ( wking) .
(Fusionné par Junio C Hamano - gitster- dans commit fb4cd88 , 06 nov.2017 )
pull: passer--signoff/--no-signoffà "git merge"la fusion peut prendre
--signoff, mais sans tirer--signoffvers le bas, elle n'est pas pratique à utiliser; permettre à 'pull' de prendre l'option et de la transmettre.
Il y a de belles réponses à cette question. J'essaierai d'ajouter une réponse plus large, à savoir ce que sont ces types de lignes / en-têtes / bandes-annonces dans la pratique actuelle. Pas tellement sur l'en-tête de signature en particulier (ce n'est pas le seul).
Les en-têtes ou bandes - annonces (↑ 1) comme «signature» (↑ 2) sont, dans la pratique actuelle dans des projets comme Git et Linux, des métadonnées efficacement structurées pour la validation. Ceux-ci sont tous ajoutés à la fin du message de validation, après la partie «forme libre» (non structurée) du corps du message. Il s'agit de paires jeton-valeur (ou clé-valeur ) généralement délimitées par deux points et un espace ( :␣).
Comme je l'ai mentionné, la «signature» n'est pas la seule bande-annonce dans la pratique actuelle. Voir par exemple ce commit , qui a à voir avec «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>
En plus de la bande-annonce de «signature» ci-dessus, il y a:
D'autres projets, comme par exemple Gerrit, ont leurs propres en-têtes et leur signification associée.
Voir: https://git.wiki.kernel.org/index.php/CommitMessageConventions
J'ai l'impression que, bien que la motivation initiale de ces métadonnées particulières ait été quelques problèmes juridiques (à en juger par les autres réponses), la pratique de ces métadonnées a progressé au-delà du simple traitement du cas de la formation d'une chaîne de paternité.
[↑ 1]: man git-interpret-trailers
[↑ 2]: Ceux-ci sont aussi parfois appelés «sanglot» (initiales), semble-t-il.
Signed-off-by:lignes de message de validation par le projet de noyau Linux (et le projet Git lui-même). Pour d'autres projets, cependant, ces lignes n'ont de sens que si le projet leur attribue un sens (par exemple, en les décrivant dans la documentation du projet; par exemple, SubmittingPatches de Linux ou Git's SubmittingPatches ).