La configuration de git peut-elle être définie sur plusieurs référentiels?

Git semble prendre en charge les valeurs de configuration à trois niveaux:

• Paramètres globaux par système (stockés dans /etc/git-core)
• Paramètres globaux par utilisateur (stockés dans ~/.gitconfig)
• Paramètres locaux par référentiel (stockés dans $REPO/.git/config)

Ces options couvrent la majeure partie de la base, mais je cherche un moyen de gérer un quatrième niveau. J'ai une (très) grande collection de référentiels pour lesquels j'ai besoin d'utiliser une valeur différente de user.emailcelle de mon habitude. Ces référentiels sont souvent créés et manipulés via des scripts automatisés, et la configuration des paramètres locaux par référentiel est fastidieuse.

Tous les référentiels en question sont situés sous un certain préfixe de chemin sur mon système local. Existe-t-il un moyen de définir une valeur de configuration quelque part qui sera héritée par tous les référentiels sous ce chemin? (Une sorte de .htaccessparamètres similaires héritent tout le long du système de fichiers.) Peut-être y aurait-il un moyen de définir des valeurs conditionnelles dans le fichier de configuration global? Quelles autres dispositions pourraient être prises dans un environnement UNIX pour faire face à un ensemble de référentiels comme le mien?

Je n'ai trouvé aucun moyen de configurer git à ce quatrième niveau. La seule façon semble être de remplacer les valeurs de configuration par commande en utilisantgit -c key=value .

Ma solution hacky actuelle consiste à définir une fonction shell qui sert de wrapper pour git. Lorsqu'il est appelé, il transmet les arguments à la commande system git, mais pas avant de vérifier le répertoire de travail actuel et d'ajouter un argument supplémentaire à la commande, le cas échéant.

function git () {
    case "$PWD" in
        /path/to/repos/*)
            command git -c user.email=alternate@credentials.org "$@"
            ;;
        *)
            command git "$@"
            ;;
    esac
}

Vous pouvez configurer l'adresse e-mail de git avec la variable d'environnement GIT_AUTHOR_EMAIL. Si vous combinez cela avec des scripts bash d'exécution lors de la saisie d'un répertoire ou d' une configuration de shell spécifique à un répertoire avec zsh, vous pouvez facilement modifier les paramètres par répertoire ou répertoire parent, par exemple, si vous entrez dans un répertoire, ~/workvous pouvez ajuster automatiquement les variables d'environnement pour modifier votre adresse e-mail. adresse.

Voir la solution basée sur la configuration de git:

http://gik.firetrot.com/index.php/2018/05/06/git-configuration-across-multiple-repositories/

Ajoutez au fichier «~ / .gitconfig»:

    [includeIf "gitdir:~/work/project1/.git"]  
      path = .gitconfig-project1  

Créez le fichier «~ / .gitconfig-project1» avec le contenu:

    [core]  
      sshCommand = "ssh -i ~/.ssh/project1 -F /dev/null"  

    [user]  
      name = user1  
      email = user1@email.com  

Sur la base de la réponse de Caleb, nous pouvons définir une gitcommande modifiée qui configure correctement en permanence tous les référentiels de ce répertoire, afin que toutes les utilisations futures de vanilla git utilisent la nouvelle configuration. J'utilise hub, qui est un autre wrapper git, donc j'ai remplacé my alias git=hubpar ceci et appelé hubdans ma fonction - si vous n'utilisez pas hub, remplacez toutes les hubinvocations par command git:

function git() {
    case "$PWD" in
        /home/robin/git/3RD_PARTY)
            hub "$@"
            # We don't know which repository was cloned / operated on, so let's just reconfigure them all
            for f in *; do
                [[ -d "$f" ]] && hub -C "$f" config user.email $my_private_email
            done
            ;;
        /home/robin/git/3RD_PARTY/*)
            hub "$@"
            hub config user.email $my_private_email
            ;;
        *)
            hub "$@"
            ;;
    esac
}

Contrairement à la réponse de Caleb, qui ne fonctionne que dans un shell (et sauf explication d'origine, uniquement dans un shell interactif), cela affecte également d'autres frontaux git qui lisent correctement la configuration git, comme emacs magit.