Comment configurer un référentiel git existant pour qu'il soit partagé par un groupe UNIX

98

J'ai un repo git existant (un simple) qui n'a jusqu'à présent été accessible en écriture que par moi. Je veux l'ouvrir à un groupe d'utilisateurs UNIX, foo, afin que tous les membres de foo puissent y pousser. Je suis conscient que je peux facilement configurer un nouveau repo git avec:

git init --bare --shared=group repodir
chgrp -R foo repodir

Mais j'ai besoin de l'opération équivalente pour un répertoire de repo existant .

Pistos
la source
4
Il y a une excellente réponse à cette question sur ServerFault (un autre site StackOverflow).
Zearin

Réponses:

115

Essayez ceci pour faire fonctionner un référentiel existant repodirpour les utilisateurs du groupe foo:

chgrp -R foo repodir                 # set the group
chmod -R g+rw repodir                # allow the group to read/write
chmod g+s `find repodir -type d`     # new files get group id of directory
git init --bare --shared=all repodir # sets some important variables in repodir/config ("core.sharedRepository=2" and "receive.denyNonFastforwards=true")
David Underhill
la source
14
J'ajouterais que vous devriez probablement également définir config.sharedRepository = true dans la configuration du repo. kernel.org/pub/software/scm/git/docs/git-config.html
Pistos
1
C'est assez proche de ce que je faisais seul, mais je voulais obtenir une confirmation externe. Merci. :) J'espérais aussi qu'il y aurait une sorte de truc git clone --shared = group, mais l'option --shared de clone fait quelque chose de complètement différent.
Pistos
5
Vous pouvez utiliser la git init --sharedcommande sur un dépôt existant pour définir la valeur de configuration. Vous devez également exécuter la chmodcommande pour obtenir les autorisations des fichiers correctement.
Spencer
1
Confirmer cela aide également si vous êtes dans le pétrin parce que quelqu'un a fait un git pulletc. en tant que root plutôt qu'en tant que www-dataou quel que soit le propriétaire et par conséquent, vous obtenez error: insufficient permission for adding an object to repository database .git/objects. Je pensais avoir corrigé la propriété de tous les fichiers / répertoires erronés en utilisant findet -type d/ type -f, mais seule cette méthode a éliminé l'erreur (probablement parce qu'un fichier dans un sous-répertoire n'était pas inscriptible en groupe?)
William Turrell
2
L'umask de l'utilisateur semble toujours s'appliquer aux fichiers nouvellement créés. Est-ce ce que vous attendez? Je pense que la documentation de core.sharedRepositoryle mentionnerait - cela semble inutile sans que les utilisateurs ne rendent tous leurs groupes de fichiers inscriptibles.
Sam Brightman
47

Dans le repo dir, exécutez les commandes suivantes:

git config core.sharedRepository group
chgrp -R foo repodir
chmod -R g+w repodir

Edit: Pour groupéviter une confusion fréquente, est un mot clé réel, vous n'êtes pas censé le remplacer par le nom du groupe.

Kixorz
la source
25
groupn'est PAS le nom du groupe :)
Pierre de LESPINAY
7
Les fichiers objet et pack doivent être immuables; ils doivent avoir les autorisations 444 / r - r - r--.
CB Bailey
3
Après avoir essayé git config core.sharedRepository dev puis en tapant git configje reçois fatal: bad config value for 'core.sharedrepository' in .git/configdans git version 1.7.0.4(et peut - être après les versions)
Kzqai
3
git config core.sharedRepository group group n'est pas le nom du groupe, mais la valeur réelle!
kixorz
Si vous avez fait l'erreur d'utiliser le nom de votre groupe au lieu de "group", ouvrez simplement .git / config dans l'éditeur de texte et modifiez la ligne core.sharedRepository pour dire "group".
Tom
44

En fusionnant les réponses @David Underhill et @kixorz , j'ai créé ma propre solution (définitive).

C'est pour les dépôts nus et les dépôts non nus . Il n'y a que peu de différences entre eux, mais de cette manière, c'est plus clair.

REPOSITAIRE NU

cd <repo.git>/                            # Enter inside the git repo
git config core.sharedRepository group    # Update the git's config
chgrp -R <group-name> .                   # Change files and directories' group
chmod -R g+w .                            # Change permissions
chmod g-w objects/pack/*                  # Git pack files should be immutable
find -type d -exec chmod g+s {} +         # New files get directory's group id

où:

  • <repo.git>est le répertoire du référentiel nu, généralement sur le serveur (par exemple my_project.git/).
  • <group-name>est le nom du groupe pour les utilisateurs git (par exemple, les utilisateurs ).

REPOSITORY NON NU

cd <project_dir>/                         # Enter inside the project directory
git config core.sharedRepository group    # Update the git's config
chgrp -R <group-name> .                   # Change files and directories' group
chmod -R g+w .                            # Change permissions
chmod g-w .git/objects/pack/*             # Git pack files should be immutable
find -type d -exec chmod g+s {} +         # New files get directory's group id

où:

  • <project_dir>est le répertoire du projet contenant le .gitdossier.
  • <group-name>est le nom du groupe pour les utilisateurs git (par exemple, les utilisateurs ).
Andrea
la source
Comme Charles l'a dit, faites aussi: chmod g-w objects/pack/*(si dépôt non nu, préfixez .git/)
Wernight
ici comment trouver le nom du groupe ou comment créer le nom du groupe?
Sujithrao
'chmod g + s find . -type d' déclenche une erreurunable to execute /bin/chmod: Argument list too long
Dr.X
Comme @ Dr.X l'a noté, chmod g+s `find . -type d`ne s'adapte pas. Utilisationfind -type d -exec chmod g+s {} +
hagello
Je pense que tous les objets lâches devraient également être en lecture seule en fonction de l'état pré-partagé. Peut-être quelque chose comme chmod g-w objects/*/*. Je ne suis pas sûr du sous-répertoire info car il est vide pour ce dépôt.
Eric le
3

Ce n'est probablement pas nécessaire, mais il convient de noter que cela git init --bare --shareddéfinit également l' option denyNonFastForwards .

git config receive.denyNonFastForwards true

La signification de cette option est la suivante:

receive.denyNonFastForwards

Si vous rebasez des commits que vous avez déjà poussés et que vous essayez de les pousser à nouveau, ou si vous essayez de pousser un commit vers une branche distante qui ne contient pas le commit vers lequel pointe actuellement la branche distante, vous serez refusé. C'est généralement une bonne politique; mais dans le cas du rebase, vous pouvez déterminer que vous savez ce que vous faites et que vous pouvez forcer la mise à jour de la branche distante avec un drapeau -f dans votre commande push.

(depuis http://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration )

nerfologue
la source
1

En plus des réponses ci-dessus pour autoriser un groupe à lire / écrire, vous devez également ajouter l'utilisateur au groupe (dites «foo»).

sudo usermod -a -G [groupname] [username]

Remarque: vous devrez d'abord créer un utilisateur s'il n'existe pas

sarvagya kumar
la source