web-dev-qa-db-fra.com

A quoi sert la fonctionnalité de déconnexion de Git?

Quel est le point de la fonctionnalité de déconnexion dans Git ?

git commit --signoff

Quand devrais-je l'utiliser, le cas échéant?

gitgit-commit
507
Clark Gaebel

La signature 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 en réalité.

Il a été introduit à la suite du poursuite de SCO , (et autres accusations de violation du droit d'auteur de la part de SCO , dont la plupart n'ont jamais été traduites en justice), en tant que - Certificat d’origine des développeurs . Il est utilisé pour indiquer que vous certifiez que vous avez créé le correctif en question ou que, à votre connaissance, il a été créé sous une licence open source appropriée, ou qu'il vous a été fourni par une licence. autrement sous ces termes. Cela peut aider à établir une chaîne de personnes qui assument la responsabilité du statut de droit d'auteur du code en question, afin de s'assurer que le code protégé non publié sous une licence de logiciel libre (open source) appropriée n'est pas inclus dans le noyau.

484
Brian Campbell

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 commit:

Add tests to statement printer.

Signed-off-by: Super Developer <[email protected]>

Il doit contenir le nom réel de l'utilisateur s'il est utilisé pour un projet open-source.

Si le responsable de la succursale a besoin de modifier légèrement les correctifs pour les fusionner, il peut demander à l’émetteur de rediffuser, mais ce serait contre-productif. Il peut ajuster le code et mettre sa signature à la fin pour que l'auteur ait toujours le mérite du correctif et non des bogues introduits.

Add tests to statement printer.

Signed-off-by: Super Developer <[email protected]>

[[email protected]: Renamed test methods according to naming convention.]
Signed-off-by: Uber Developer <[email protected]>

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

62
Andrzej Rehmann

git 2.7.1 (février 2016) précise que dans commit b2c150d (5 janvier 2016) par David A. Wheeler (david-a-wheeler) .
(Fusionné par Junio ​​C Hamano - gitster - dans commit 7aae9ba , 5 février 2016)

git commit page de manuel inclut désormais:

-s::
--signoff::

Ajoutez la ligne Signed-off-by du commetteur à la fin du message du journal de validation.
La signification d'une signature dépend du projet, mais il certifie généralement que l'auteur 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 --signoff

Modifiez divers fichiers de document (page de manuel) pour expliquer plus en détail ce que --signoff signifie.

Ceci a été inspiré par " article précédent" Bottomley: Une proposition modeste sur le DCO " " (Certificat d'origine de développeur) où paulj a noté:

Le problème que j'ai avec DCO est que l'ajout d'un argument "-s" à git commit ne signifie pas vraiment que vous avez même entendu parler de DCO ( La page de manuel git commit ne fait aucune mention du DCO où que ce soit ).

Alors, comment la présence de "signed-off-by" peut-elle impliquer de quelque manière 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 ne disant rien de plus que "Renvoyer ceci avec signed-off-by afin que je puisse le commettre".

En développant la documentation de git, il sera plus facile d'affirmer que les développeurs ont compris --signoff lorsqu'ils l'utilisent.

Notez que cette signature est maintenant (pour Git 2.15.x/2.16, T1 2018) également disponible pour git pull.

Voir commit 3a4d2c7 (12 oct 2017) par 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 en passant --signoff vers le bas, son utilisation est peu pratique; laissez 'pull' choisir l'option et la transmettre.

28
VonC

Il y a quelques bonnes réponses à cette question. Je vais essayer d’apporter une réponse plus large, notamment en ce qui concerne ces types de lignes/en-têtes/remorques dans la pratique actuelle. Pas tellement sur l’en-tête de signature en particulier (ce n’est pas le seul).

En-têtes ou remorques (↑ 1) comme "signature" ( ↑ 2) est, dans la pratique actuelle dans des projets comme Git et Linux, des métadonnées bien structurées pour le commit. 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. Ce sont des paires jetons valeur (ou clés – valeur ) généralement délimités par deux points et un espace (:␣).

Comme je l'ai mentionné, la signature n'est pas la seule bande-annonce de la pratique actuelle. Voir par exemple this 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 <[email protected]>
 Acked-by: Hugh Dickins <[email protected]>
 Reviewed-by: Michal Hocko <[email protected]>
 Cc: Andy Lutomirski <[email protected]>
 Cc: Kees Cook <[email protected]>
 Cc: Oleg Nesterov <[email protected]>
 Cc: Willy Tarreau <[email protected]>
 Cc: Nick Piggin <[email protected]>
 Cc: Greg Thelen <[email protected]>
 Cc: [email protected]
 Signed-off-by: Linus Torvalds <[email protected]>

En plus de la remorque d’approbation ci-dessus, il existe:

  • “Cc” (a été informé du correctif)
  • "Acked-by" (reconnu par le propriétaire du code, "me semble bon")
  • “Revu par” (commenté)
  • “Rapporté et testé par” (rapporté et testé le problème (je suppose))

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

Morale de l'histoire

J’ai l’impression que, bien que la motivation initiale de ces métadonnées en particulier fût liée à certaines questions juridiques (à en juger par les autres réponses), la pratique de telles métadonnées n’a pas évolué au-delà du simple cas de la formation d’une chaîne d’auteurs.

[↑ 1]: man git-interpret-trailers
[↑ 2]: Celles-ci sont aussi parfois appelées "s-o-b" (initiales), semble-t-il.

15
Guildenstern