Y a-t-il des pièges à mettre $ HOME dans git au lieu de faire des liens symboliques entre les fichiers point?


38

Pendant de nombreuses années, j'ai fait $HOMEvérifier tout mon répertoire en subversion. Cela inclut tous mes fichiers de points et profils d’applications, de nombreux scripts, outils et hacks, la structure de mon répertoire personnel de base préféré, ainsi que quelques projets inhabituels et un entrepôt de données aléatoires. C'était une bonne chose. Tant que ça a duré.

Mais c'est devenu incontrôlable. La vérification de base est la même sur des dizaines de systèmes, mais tout ce matériel n’est pas adapté à toutes mes machines. Il ne joue même pas bien avec différentes distributions.

Je suis en train de nettoyer la maison - séparer les données de leur lieu d'origine, séparer certains scripts en projets distincts, réparer des liens brisés dans des éléments devant être automatisés, etc.

Mon intention est de remplacer subversionpar gitpour la vérification au plus haut niveau de $HOME, mais j'aimerais réduire cela à tout ce que je voudrais avoir sur TOUS mes systèmes, à savoir les fichiers de points, quelques répertoires et quelques scripts personnalisés de base.

En lisant en ligne, beaucoup de gens semblent le faire en utilisant l’approche des liens symboliques: cloner dans un sous-répertoire, puis créer des liens symboliques à partir $HOMEdu référentiel. Ayant eu le $HOMEcontrôle total de ma version pendant plus de 10 ans, je n’aime pas l’idée de cette approche et je ne comprends pas pourquoi les gens semblent si opposés à la méthode de paiement direct. Y a-t-il des pièges dont je devrais avoir connaissance en gittant que commande de niveau supérieur pour $HOME?

Post-scriptum En partie comme un exercice de bonne codage, je prévois aussi de rendre publique ma vérification de racine sur github. Il est effrayant de constater la quantité d’informations confidentielles relatives à la sécurité que j’ai permis de collecter dans des fichiers pouvant être partagés sans hésiter! Mot de passe WiFi, clés RSA non passphrasées, etc. Eeek!


5
Curieux de savoir pourquoi $ HOME devrait pouvoir être partagé sans hésiter… Même les clés privées cryptées RSA ne devraient pas être partagées.
derobert

3
si vous parlez de mettre le contenu de votre répertoire personnel dans git, sachez qu'il est difficile (mais pas impossible) de parcourir l'historique de git et de supprimer soigneusement les éléments sensibles de manière permanente (git est conçu pour éviter de perdre des objets), et N'oubliez pas non plus que lorsque vous changez de branche ou d'extraction, une révision antérieure gitmodifie les autorisations de vos fichiers 644après l'expiration, ce qui est préjudiciable pour des éléments tels que les clés ssh privées. Cependant, etckeeperc'est une solution pour utiliser git avec des permissions pour / etc /
cwd

@derobert: Je suis bien conscient de cela. Je ne parlais pas de rendre $ HOME public, mais uniquement des fichiers de points et des scripts pratiques. C’est là que j’ai trouvé des choses qui n’appartiennent pas. Et oui, je devrais être en mesure de partager mon .zshrc, .vimrcet les choses semblables sans avoir à les aseptiser d' abord!
Caleb

4
Si vous ne l'avez pas vu, consultez le wiki et les listes de diffusion vcs-home , qui sont essentiellement des personnes qui discutent exactement de ce sujet - comment garder votre $ HOME sous contrôle de révision.
Jim Paris

Je ne sais pas à quel point vous pouvez changer le comportement de git, mais au moins sa façon de fonctionner en dehors du référentiel debian est plutôt gourmand quand il s'agit de rechercher des fichiers suivis / non suivis / modifiés et cela automatiquement se sent responsable de chaque dossier. Mrb a déjà dit cela. Parfois, ce comportement glouton m'énerve, même dans des projets relativement petits, que je ne voudrais pas que cela soit dans mon répertoire personnel. Pourquoi voulez-vous utiliser git? J'utilise également un système de gestion de version pour synchroniser mes fichiers de configuration sur des hôtes et je suis assez satisfait de CVS car c'est tellement simple! Git est très (aussi!) Puissant pour cela
Bananguin

Réponses:


17

Oui , il existe au moins un écueil majeur lorsqu’on envisage gitde gérer un répertoire personnel qui ne pose pas de problème subversion.

Git est à la fois gourmand et récursif par défaut .

Subversion ignorera naïvement tout ce qu’il ne sait pas et arrête de traiter les dossiers vers le haut ou le bas de votre caisse quand il atteint un dossier qu’il ne connaît pas (ou qui appartient à un autre référentiel). Git, quant à lui, continue à récurer dans tous les répertoires enfants, rendant les extractions imbriquées très compliquées en raison de problèmes d'espace de nommage. Etant donné que votre répertoire personnel est probablement également le lieu où vous passez à la caisse et que vous travaillez sur divers autres référentiels git, le fait d’avoir votre répertoire personnel dans git risque de vous rendre la vie impossible.

En fin de compte, c’est la principale raison pour laquelle les utilisateurs extraient leurs fichiers .NET dans un dossier isolé, puis un lien symbolique vers ce dernier. Cela empêche la manipulation lorsque vous faites autre chose dans n'importe quel répertoire enfant de votre $HOME. Bien que ce soit purement une question de préférence si vous voulez que votre maison soit subversion, cela devient une nécessité si vous utilisez git.

Cependant , il existe une solution alternative. Git autorise quelque chose appelée "fausse racine" où toute la machinerie du référentiel est cachée dans un autre dossier pouvant être physiquement séparé du répertoire de travail d'extraction. Le résultat est que le toolkit git ne sera pas dérouté: il ne verra même pas votre référentiel, seulement la copie de travail. En définissant quelques variables d'environnement, vous pouvez indiquer à git où trouver les marchandises pour ces moments où vous gérez votre répertoire personnel. Sans les variables d'environnement définies, personne n'est le plus sage et votre maison a l'apparence d'un fichier classique.

Pour rendre cette astuce un peu plus fluide, il existe d'excellents outils. La liste de diffusion vcs-home semble être l’endroit idéal pour commencer, et la page à propos contient un récapitulatif pratique des howtos et des expériences des utilisateurs. Tout au long du chemin, vous trouverez quelques petits outils astucieux comme vcsh , mr . Si vous souhaitez conserver votre répertoire personnel directement dans git, vcsh est presque un outil indispensable. Si vous divisez votre répertoire personnel en plusieurs répertoires en coulisse, associez-le vcshà mrun moyen rapide et pas très sale de gérer tout cela en même temps.


2
mais pourquoi ne pas simplement ajouter '*' à votre fichier .gitignore? De cette façon, git ignorera tout sauf les fichiers déjà présents dans le référentiel, et vous pourrez ajouter de nouveaux fichiers avec git add -f <file>.
ALiX

@ALiX: Parce que les gitoutils continueraient à considérer que vous travaillez sur votre repo de répertoire local même si vous vous trouviez dans un sous-répertoire qui était un référentiel git distinct pour un projet. Cette solution rendrait votre répertoire personnel entier hors de portée de tout autre travail git.
Caleb

5
mais un '*' dans votre .gitignore signifie que tous les fichiers qui ne sont pas dans votre référentiel home-dir sont ignorés. et quand vous extrayez un nouveau repo git dans un sous-répertoire, tout devrait quand même fonctionner comme prévu (je pense). Pour autant que je sache, les outils git rechercheront le premier répertoire .git lors de la progression dans la hiérarchie des répertoires. Ainsi, lorsque vous travaillerez dans le sous-répertoire, le référentiel git approprié sera utilisé. Bien sûr, si vous utilisez les variables d'environnement de git, je suppose que les choses pourraient devenir compliquées. Mais sinon, je ne vois pas pourquoi cela ne fonctionnerait pas.
ALiX

@ ALiX a raison. Les dépôts git imbriqués semblent fonctionner correctement tant que vous les gitignorez dans le dépôt parent. Je me demande quels sont les inconvénients de cette approche très simple, mis à part les éventuels problèmes liés aux variables d'environnement de git.
Evanrmurphy

1
Expérimente avec cela aujourd'hui. Je pense que cela /*fonctionne mieux que *parce qu'il ignore toujours tout par défaut mais rend beaucoup plus facile l'ajout de répertoires. Au lieu d’ git add -futiliser des !modèles -prefixés tels que !/.vimrcet !/.gitignore(pour le fichier .gitignore lui-même) pour inclure explicitement des éléments dans le référentiel.
Evanrmurphy

14

Je ne voudrais pas que tout mon répertoire personnel soit enregistré dans le contrôle de version simplement parce que cela signifie que tous les sous-répertoires dans lesquels je vais avoir ont le contexte de contrôle de version de mon répertoire personnel. Des commandes comme, par exemple, git checkoutauraient une action réelle dans ce cas, posant des problèmes si j'exécute accidentellement quelque chose à partir du mauvais répertoire, qu'il s'agisse de quelque chose en gitsoi ou d'un script qui appelle git.

Cela rend également plus probable l'ajout de quelque chose que vous ne voulez pas dans le rapport, ce qui n'aurait pas été un problème si vous aviez tout enregistré, mais qui devient maintenant un problème. Que faire si vous ajoutez accidentellement un fichier de clé privée (peut-être par habitude) et le poussez vers github?

Cela dit, j’estime que les principaux inconvénients ne sont pas vraiment techniques - je veux juste me sauver de moi-même.

En ce qui concerne les liens symboliques: vous pouvez cloner votre rapport dans un sous-répertoire et créer un script qui met à jour tous les liens symboliques devant être mis à jour. La quantité de maintenance requise pour ce script peut compenser les avantages de l'avoir du tout, cependant; symlinking pourrait s'avérer être moins de travail.

Avec les liens symboliques, vous pouvez également facilement ajouter des ajouts spécifiques à la distribution (ou même à l’hôte) qui sont archivés dans git. Votre script symlink-update ignorera les fichiers destinés à des plates-formes incompatibles ou à des hôtes différents et ne mettra à jour que ceux appropriés.

Quelque chose comme:

HOMEREPO=$HOME/homerepo
HOST=$(hostname)
UNAME=$(uname)

for dotfile in $HOMEREPO/shared/* $HOMEREPO/host-$HOST/* $HOMEREPO/uname-$UNAME/*
do
    target=$HOME/$(basename $dotfile)
    [ ! -r $target ] && ln -s $dotfile $target
done

Personnellement: j'utilise des liens symboliques et je ne répertorie pas de liens symboliques; seuls les fichiers à l'intérieur. Cela me donne une certaine souplesse pour apporter des modifications locales à ces répertoires (par exemple, ajouter / supprimer des fichiers). Configurer mon compte sur un nouveau système est fastidieux car je dois recréer tous les liens symboliques à la main.


Toutes les gitcommandes que je lance s’appliqueraient soit au répertoire de base lui-même, soit seraient enterrées au moins dans un répertoire situé dans un répertoire non validé. L'utilisation de svncette isolation de dossier est très efficace et ne m'a posé aucun problème depuis une décennie. Votre premier paragraphe indique autre chose. Est-ce vraiment une différence dans la façon dont gitfonctionne?
Caleb

De plus, mes configs et scripts ont déjà une logique conditionnelle pour différents hôtes et plates-formes intégrés. Par conséquent, utiliser un script pour configurer différents liens en conditionnelle ne semble pas être un gain giten termes de gestion des branches. Encore quelque chose me manque ou est-ce que cela va tomber par préférence?
Caleb

3
L'isolation d'un dossier n'isole pas vraiment git- vous en êtes sûr svn- mais, à titre d'exemple, git init foo && mkdir -p foo/bar/baz/spam && cd foo/bar/baz/spam && git status(ou d'autres commandes git), vous indiquez que vous êtes toujours dans foole contexte du contrôle de version.
mrb

Configs & scripts: Tous les fichiers dotfiles ne prennent pas en charge les conditions, c'est pourquoi j'ai suggéré l'approche alternative. Ce sont toutes des raisons pour lesquelles, je pense, les gens préfèrent ne pas utiliser le contrôle de version $HOME- et le versionnage n'a pas vraiment de valeur pour dotfiles imo - mais c'est finalement votre répertoire personnel, donc si vous préférez utiliser git et que ce ne sont pas des problèmes pour vous, fonce!
mrb

Merci pour l'info. En fait, votre commentaire sur le fait que git ne permet pas l’isolement est le bit le plus utile. Vous pourriez en tenir compte dans votre réponse. Subversion se comporte très différemment sur ce point et est significatif pour ce cas d'utilisation.
Caleb

6

Pour donner un autre point de vue: j'ai mon $ HOME sous git depuis quelque temps maintenant et je n’ai trouvé aucun inconvénient. Je ne synchronise évidemment pas ce git repo sur github; J'utilise un service qui a des pensions privées. De plus, je ne mets aucun fichier multimédia, téléchargement ou package sous le contrôle de Git.

  • git status est une sorte de liste de contrôle "à faire, à nettoyer".

  • J'ai un ~/tmppour les choses temporaires, qui est gitignored.

  • J'aime voir dans git statustout ce qu'un logiciel récemment installé ose ajouter à mon $ HOME, et supprime souvent ces fichiers, voire même désinstaller les coupables.

  • J'ajoute manuellement les fichiers et répertoires locaux vraiment utiles .gitignore, qui présentent l'avantage de "savoir ce que vous faites lors de l'installation".

  • Si je construis une nouvelle VM ou installe un nouveau PC, je clone simplement ma maison distante sur $ HOME et j'ai immédiatement tout ce dont j'ai besoin sous la main.

  • Des choses comme vundle for vim plugins ne sont plus nécessaires.

Je n'aime pas la complexité. Lorsque je modifie un fichier rcf, je le fais, engage et pousse. Ensuite, par réflexe, j’ai tiré dans $ HOME tous les deux jours et j’ai toujours la dernière configuration. C'est aussi simple que ça.

Machines actuellement soumises à ce régime: ordinateur portable à la maison, ordinateur de travail, machine virtuelle de travail, plus 3 ou 4 serveurs distants.


Avez-vous d'autres caisses de contrôle git imbriquées dans votre maison?
Caleb le

Non, je mets d'autres choses dans un répertoire / work et ne clone pas de petits outils comme Vim Pugins.
gb.

1
J'ai un travail dans un ~ / Sites et je fais cette approche aussi, il n'y a pas de problème avec les imbéciles de git imbriqués
philfreo

1
J'utilise cette configuration depuis un moment. J'ai un 'alias sq = git status -uno' et ne me dérange pas beaucoup avec .gitignore (de temps en temps, je regarde tout ce qui est cruel et ensuite je dis "meh"). Je n'ai jamais eu de problèmes avec les dépôts imbriqués git. J'ai un serveur privé sur lequel j'ai effectué une application git init --baresur ssh (bien que je ne mette pas de mots de passe dans le référentiel, mes fichiers de notes s'y trouvent).
Unhammer

5

J'ai essayé les deux et j'ai préféré l' approche des liens symboliques à la fin:

  • Départ n'importe où
  • make install
  • Déconnectez-vous et reconnectez-vous pour charger les paramètres X

Désavantages:

  • Avoir à déplacer les fichiers vers le référentiel avant de les ajouter
  • Maintenir la liste des liens symboliques dans le Makefile

Avantages:

  • Pas besoin d'un énorme .gitignore(j'ai 133 fichiers de points dans ~mon humble boîte Ubuntu)
  • Peut garder les scripts de maintenance et autres ~éléments liés (tels que Makefileet cleanup.sh) à l'écart
  • Peut-on contrôler la version des paramètres personnels et publics séparément

Restrictions

  • Contrairement à @mrb, je ne crée que des liens symboliques dans ~. Cela simplifie la création de liens symboliques et rend facile la détection de nouveaux fichiers, par exemple ~/.vim, au prix de très rares .gitignoretravaux de maintenance.

Les deux derniers avantages ont fait pencher la balance dans mon cas - je ne veux pas encombrer le répertoire personnel, et je veux que le contenu privé et le contenu public soient clairement séparés.

La seule application que je connaisse qui ait (ou du moins eu) des problèmes de gestion des liens symboliques est Pidgin - Elle écrase continuellement mes liens symboliques avec des fichiers ordinaires.


Merci pour vos commentaires sur les avantages et les inconvénients de chaque approche. Dans mon suivi, j'ai découvert qu'il existe une troisième approche qui pourrait tirer le meilleur parti des deux mondes si vous êtes en mesure de configurer le câblage supplémentaire pour commencer.
Caleb

3

En voici une: si vous essayez de le faire git rebase -i --rootet que vous avez archivé .gitconfigle premier commit dans le référentiel, git supprimera temporairement le .gitconfigfichier, ce qui l'empêchera de terminer l'opération de rebasement car il nécessite votre nom et votre adresse email. cela, qui sont stockés dans ce fichier.

Vous pouvez les configurer à nouveau git rebase --continue, mais après l'avoir fait et terminé l'opération de rebase, mon dépôt git avait obtenu une validation vide sans message de validation avant la validation qui était auparavant la première validation dans le référentiel, ce que je ne connais pas. comment se débarrasser de.

Je ne sais pas ce qui se passe si vous le faites à la git rebase -i <commit>place, et .gitconfigest enregistré avec tout commit ultérieur <commit>.

La solution la plus simple est peut-être de s’abstenir d’ajouter .gitconfigdes données au référentiel et de les lister .gitignore.


2

Voici comment je le fais:

  1. installer un linux propre (pas nécessaire, mais rend la vie plus agréable à l'étape 4)
  2. installer etckeeper
  3. cours git initchez toi
  4. Créez .gitignore et ajoutez tout ce qui semble ne pas vous intéresser ou qui pourrait changer beaucoup. Assurez-vous d'ajouter des choses comme *.cache, *.locketc. Je ne recommande pas d'ajouter/*parce que vous ne serez pas averti automatiquement quand quelque chose de nouveau est ajouté à votre maison. C’est une approche de liste noire par opposition à une liste blanche, où je veux fondamentalement conserver ma configuration pour tous les logiciels, à l’exception des éléments volatiles et de certains logiciels qui ne me dérangent pas. Lorsque vous fusionnez, migrez ou comparez des systèmes ultérieurement, il est très pratique de tout différencier. Vous pouvez configurer vos nouveaux systèmes beaucoup plus rapidement que si vous aviez simplement .bashrc et quelques autres fichiers. De cette façon, vous conserverez la configuration que vous auriez peut-être définie par le biais de l'interface graphique et vous ne saurez pas quels fichiers dot stockent les paramètres. (S'il s'avère que vous avez déjà commis des fichiers volatiles, vous pouvez toujours dire à git d'assumer-inchangé)
  5. courir etckeeper init -d /home/username
  6. courir git commit -d /home/username
  7. configurez des alias dans votre shell pour rendre la ligne de commande plus agréable, comme homekeeper checkout

Etckeeper est utilisé pour stocker des métadonnées, comme des autorisations sur vos fichiers (plutôt important pour certaines choses comme les clés ssh). Vous devriez maintenant avoir un crochet de pré-validation qui enregistrera automatiquement les métadonnées. Je ne suis pas si sûr de post-checkout. Vous devriez probablement utiliser etckeeper checkout xxx -d /home/userJe vais examiner un peu plus et élaborer cette réponse.


-1

Mon problème majeur avec l'utilisation de Git sur le répertoire de base est que Git ne stocke pas les attributs de fichiers tels que les autorisations de fichiers et les horodatages. Pour moi, il est important de savoir quand certains fichiers ont été créés, cela peut ou peut ne pas être le cas pour vous. En outre, la perte d'autorisations sur des fichiers et des répertoires .sshest problématique. Je comprends que vous envisagez de .sshne pas utiliser Git, mais il y aura d’autres endroits où les autorisations pourraient avoir de l’importance (comme les sauvegardes de sites Web non compressées).


Ceci est trompeur sinon factuel. Git par défaut préserve de nombreux attributs de fichiers, y compris les autorisations. Cela fait un .sshcertain temps que je me tiens au courant sans problème, les autorisations sécurisées appropriées sont préservées. Ce qu’il ne fait pas dans la configuration de base, c’est de conserver la propriété ou les horodatages; Cependant, si l'un de ces problèmes pose problème pour un cas d'utilisation spécifique, certains plug-ins peuvent intégrer la gestion de ces propriétés supplémentaires au flux de travaux standard (voir metastore ou git-cache-meta).
Caleb

Même s'il ne les stocke pas, en quoi est-ce pire que d'avoir un répertoire personnel, pas dans vcs? git ne va pas écraser activement les mtimes à moins que vous ne lui demandiez de modifier un fichier.
poolie

-1

Une solution basée sur git est particulièrement utile si vous devez déployer vos fichiers sur différentes machines, et encore plus si vous avez des parties communes à toutes les machines et des parties spécifiques à certaines machines. Vous pouvez créer plusieurs référentiels et utiliser un outil tel que multigit ou vcsh pour les cloner dans le même répertoire (votre répertoire personnel dans ce cas).


Merci, mais peut-être que vous avez raté la question. Je suis bien conscient des utilisations possibles (d'où la raison pour laquelle je voulais le faire en premier lieu), cette question portait sur les pièges que quelqu'un de nouveau pourrait faire avec git (comme je l'étais quand j'ai demandé) pourrait ne pas être au courant. . Cela ne semble pas répondre à cette question du tout.
Caleb
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.