Question À quoi sert la fonction de déconnexion de Git?


Quel est le but du Fonction de signature dans Git?

git commit --signoff

Quand devrais-je l'utiliser, voire pas du tout?


443
2017-12-25 22:30


origine


Réponses:


La signature est une exigence pour intégrer 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 dans le sillage du Procès SCO, (et autres accusations de violation du droit d'auteur de SCO, dont la plupart n’ont jamais été traduits en justice), en tant que Développeurs Certificat d'origine. Il est utilisé pour dire que vous certifiez que vous avez créé le correctif en question ou que vous certifiez que, au meilleur de vos connaissances, il a été créé sous une licence open source appropriée ou qu'il vous a été fourni par quelqu'un. d'autre dans ces conditions. Cela peut aider à établir une chaîne de personnes qui prennent la responsabilité du statut de copyright du code en question, afin de garantir que le code protégé par des droits d'auteur ne soit pas publié sous une licence de logiciel libre (open source) appropriée.


430
2017-12-25 22:39



La déconnexion 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 to statement printer.

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

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

Si le responsable de la succursale doit modifier légèrement les correctifs afin de les fusionner, il pourrait demander au déposant de rediffuser, mais cela serait contre-productif. Il peut ajuster le code et mettre sa signature à la fin pour que l'auteur reçoive toujours le crédit pour le patch et non les bugs introduits.

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>

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


56
2017-12-26 17:36



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

git commit page de manuel comprend maintenant:

-s::
--signoff::

Ajouter Signed-off-by ligne par l'auteur à la fin du message du journal de validation.
  La signification d'une signature dépend du projet, mais 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 http://developercertificate.org/ pour plus d'informations).


Développer la documentation décrivant --signoff

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

Cela a été inspiré par "Lwn article 'Bottomley: une modeste proposition sur le DCO'"(Certificat d'origine du développeur) où pajj a noté:

Le problème que j'ai avec DCO est que là ajouter un "-s"L'argument de git commit ne signifie pas vraiment que vous avez même entendu parler du DCO (la git commit page de manuel ne fait aucune mention du DCO nulle part), peu importe réellement vu cela.

Alors, comment la présence de "signed-off-by"de quelque manière que ce soit, l’émetteur accepte et s’engage envers le DCO? Combiné avec le fait, j’ai vu des réponses sur des listes à des patchs sans SOB qui ne disent rien de plus" signed-off-by alors je peux le commettre ".

L’extension de la documentation de git facilitera l’argument selon lequel les développeurs ont compris --signoff quand ils l'utilisent.


Notez que cette déconnexion est maintenant (pour Git 2.15.x / 2.16, Q1 2018) disponible pour git pull ainsi que.

Voir commettre 3a4d2c7 (12 oct. 2017) par W. Trevor King (wking).
(Fusionné par Junio ​​C Hamano - gitster - dans commenter fb4cd88, 06 Nov 2017) 

pull: passer --signoff/--no-signoff à "git merge"

la fusion peut prendre --signoff, mais sans passer --signoff vers le bas, ça   est incommode à utiliser; autoriser 'pull'pour prendre l'option et la passer   par.


25
2018-02-06 06:22



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

En-têtes ou bandes annonces (↑ 1) comme "sign-off" (↑ 2) est, en cours pratique dans des projets comme Git et Linux, des métadonnées structurées de manière efficace pour le commit. Ceux-ci sont tous ajoutés à la fin du message de validation, après la partie "libre" (non structurée) du corps du message. Ceux-ci sont valeur de jeton (ou valeur clé) paires typiquement délimitées par un deux points et un espace (:␣).

Comme je l'ai mentionné, «signer» n'est pas la seule bande-annonce de 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 "sign-off" ci-dessus, il y a:

  • "Cc" (a été averti du patch)
  • "Acked-by" (reconnu par le propriétaire du code, "semble bon pour moi")
  • "Revu par" (révisé)
  • "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 signification associée pour eux.

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

Morale de l'histoire

J'ai l'impression que, bien que la motivation initiale pour cette certaines métadonnées étaient des questions juridiques (à en juger par réponses), la pratique de ces métadonnées a progressé au-delà de traiter le cas de former une chaîne de paternité.

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


7
2017-12-15 13:06