Git hook pour détecter push --mirror

Question

à côté d'un référentiel Git principal sur un serveur (avec Gitolite) Je voudrais avoir une possibilité pour chaque développeur de mettre en place un miroir son propre référentiel local. Ce n'est pas difficile.

Cependant, je souhaite désactiver git push --mirror sur le référentiel principal du serveur Git, pour éviter les erreurs si un développeur visse la mise en miroir. Je pense que le meilleur endroit est un crochet, peut-être le crochet de mise à jour. Mais je ne peux pas trouver comment détecter dans un crochet de serveur, que la commande push --mirror a été exécutée sur l'ordinateur client.

La solution côté client n'est pas possible car nous utilisons également Eclipse Git (JGit).

Answer 1

Si vous voulez vraiment faire cela avec des crochets, le crochet à utiliser serait pre-receive. Vous ne pouvez pas détecter directement qu'il s'agit d'un push miroir, car il n'y a rien dans les données envoyées qui le dit, mais vous pouvez être intelligent et le faire correctement presque tout le temps. Le hook de pré-réception reçoit une liste de refs à mettre à jour, avec des valeurs anciennes et nouvelles, et s'il se termine avec un statut différent de zéro, le push entier est abandonné. Probablement la principale caractéristique distinctive d'une poussée de miroir est qu'elle pousse aussi des branches éloignées, telles quelles. Je ne peux pas penser à tous les cas normaux que vous feriez cela, donc vous pouvez simplement vérifier que, quelque chose comme:

#!/bin/bash 
while read old new ref; do 
    if [[ "$ref" =~ "^refs/remotes/.*" ]]; then 
     echo "You're pushing remote branches - did you use 'push --mirror'?" 
     echo "Rejecting push" 
     exit 1 
    fi 
done 

Tout push --mirror * se déclencherait ce crochet, il devrait donc vous couvrir; il est bien sûr un peu trop zélé mais à moins que vous n'ayez l'intention de maintenir des succursales éloignées dans votre dépôt central, cela n'aura aucune importance.

_{* Sauf un vraiment très manuel, où quelqu'un pousse d'un repo sans télécommandes en spécifiant manuellement git push --mirror <url>, mais j'espère vraiment que vous n'avez pas à vous en préoccuper.}

---

Je recommande toujours gitolite. Il ne vous permet pas vraiment de refuser les miroirs, mais cela peut aider un peu, et fournir beaucoup d'autres choses utiles. Notez que la gitolite vous permet d'ajouter vos propres crochets, donc vouloir utiliser cela ne devrait pas vous empêcher d'obtenir tous les bienfaits de la gitolite. Si vous n'allez pas utiliser Gitolite, vous devriez vraiment, vraiment, mettre core.logAllRefUpdates à true dans le repo central, de sorte que si quelqu'un obtient un mauvais coup de votre part, vous pouvez récupérer.

choses liées à ce problème que gitolite ferait pour vous:

• vous permettent de limiter la plupart des développeurs de ne pouvoir accéder à des branches clés, et les empêcher de tout supprimer (utilisez RW, pas RW+ autorisations) , donc les dommages qu'ils peuvent faire sont limités - la suppression des branches est probablement la pire partie d'un accès de journal plus complètement, de sorte que si quelqu'un fait des dégâts, vous pouvez voir exactement qui c'était et ce qu'ils ont fait, et l'éviter à l'avenir

Answer 2

Je n'essaierais pas de 'rafistoler' la sécurité en utilisant des crochets. Ils n'ont pas été conçus pour ce type de contrôle d'accès.

Vous pourriez regarder la gitolite. Il vous permet de contrôler l'accès sur une base pré-branche.

Voir https://github.com/sitaramc/gitolite/wiki