Nous aimerions utiliser Git pour maintenir des configurations système. Parce que parfois les données de configuration existent en dehors de / etc., nous avons commencé à faire quelque chose comme celui-ci sur nos systèmes:
GIT_WORK_TREE=/ git status
3 Réponses :
Ceci est un devinez que vous pourriez utiliser pour rechercher plus loin, mais je soupçonne que le comportement de GIT's "Rechercher le .git " est interagi avec le fait que < code> / est son propre répertoire parent. Peut-être que la logique "STOP à la racine" a une erreur de type de fenence.
Ah, git. Toujours une nouvelle surprise quelque part. J'aime ta suppose cependant. +1
C'était aussi ma supposition (et pourquoi je soupçonne que définir Git_work_tree le réparerait). Je me demande simplement s'il y a une manière plus gracieuse de travailler autour du comportement ... une option de configuration GIT? Je vois qu'il y a une nouvelle version de Git Out (nous courons 1.63); Peut-être que je devrais voir si ce seuil se comporte de la même manière.
@Nr: salut là-bas! J'aime bien git que les alternatives. Je pense qu'ils tous ont des surprises (comme Subversion's "de la surprise! Vous ne pouvez pas réellement utiliser svndump / svnload si vous avez déplacé des objets!").
@larsks: sonne digne d'avoir un bug déposé pour moi :)
Hélas, la mise à niveau vers la version actuelle de GIT ne résout pas ce problème.
Réglage de l'option Cela fonctionne beaucoup mieux que de définir git_work_tree dans l'environnement. Yay! corporel.worktree sur le référentiel prend en charge cette option:
Aussi, merci Stackoverflow.com/Questtions/505467/...
Ceci sera corrigé dans GIT 2.4.1+ (Q2 2015).
Voir commit 84ccad8 par Jeff King ( peff ) et fusionné dans 7502b23 .
init : ne définissez pas corporel.worktree lors de l'initialisation /. git
Si vous créez un référentiel git dans le répertoire racine avec " git init / ", nous écrivons à tort un Core.worktree entrée.
Ce n'est pas mauvais , dans le sens où il est correct de définir core.worktree lorsque nous n'avons pas besoin de. Mais il est inutilement surprenant que vous déplaciez plus tard le répertoire .git sur un autre chemin (qui déplace généralement l'arbre de travail relatif, mais est aléatoire s'il existe un ensemble de travail explicite).
Le problème est que nous vérifions si Core.workTree est nécessaire en voyant si nous pouvons rendre le git_dir en concaténant "/.git" sur l'arbre de travail .
Cela conduirait à " //. git " dans ce cas, mais nous avons réellement " /. Git "
(sans la barre oblique doublée).
(c'est pourquoi corporel.worktree est incorrectement défini ici, lorsque git init est effectué dans le dossier racine / )
Nous pouvons résoudre ce problème en cas d'enregistrement spécial. J'ai également divisé la logique dans sa propre fonction pour rendre le conditionnel un peu plus lisible (et utilisé skip_prefix, que je pense en fait un peu plus évident ce qui se passe).
aucun test, car nous aurions besoin de pouvoir écrire à "/" pour le faire.
Je l'ai confirmé manuellement:
xxx
trouve toujours le niveau supérieur correctement (comme " / ") et ne définit aucune variable Core.worktree . .
Remarque: Git 2.4.1+ Fixera ceci (Q2 2015). Voir Ma réponse ci-dessous .