172 votes

rsync exclure selon .gitignore & .hgignore & svn:ignore comme --filter=:C

Rsync comprend une option très pratique. --cvs-exclude pour "ignorer les fichiers de la même manière que CVS", mais CVS est obsolète depuis des années. Existe-t-il un moyen de faire en sorte qu'il exclue également les fichiers qui seraient ignorés par les systèmes de contrôle de version modernes (Git, Mercurial, Subversion) ?

Par exemple, j'ai beaucoup de projets Maven extraits de GitHub. En général, ils comprennent un .gitignore en énumérant au moins target le répertoire de construction Maven par défaut (qui peut être présent au niveau supérieur ou dans les sous-modules). Étant donné que le contenu de ces répertoires est entièrement jetable et qu'il peut être beaucoup plus important que le code source, je voudrais les exclure lorsque j'utilise rsync pour les sauvegardes.

Bien sûr, je peux explicitement --exclude=target/ mais cela supprimera accidentellement des répertoires non liés qui s'appellent simplement target et ne sont pas censés être ignorés.

Et je pourrais fournir une liste complète des chemins absolus pour tous les noms de fichiers et les modèles mentionnés dans n'importe quel fichier de la liste. .gitignore , .hgignore ou svn:ignore sur mon disque, mais ce serait une liste énorme qui devrait être produite par une sorte de script.

Puisque rsync n'a pas de support intégré pour les extractions VCS autres que CVS, y a-t-il une bonne astuce pour lui fournir leurs modèles d'ignorance ? Ou une sorte de système de rappel par lequel on peut demander à un utilisateur script si un fichier/répertoire donné doit être inclus ou non ?

Mise à jour : --filter=':- .gitignore' comme suggéré par LordJavac semble fonctionner aussi bien pour Git que --filter=:C le fait pour CVS, du moins sur les exemples que j'ai trouvés, bien qu'il ne soit pas clair si la syntaxe est une correspondance exacte. --filter=':- .hgignore' ne fonctionne pas très bien pour Mercurial ; par exemple, un fichier de type .hgignore contenant une ligne comme ^target$ (l'équivalent Mercurial de Git /target/ ) n'est pas reconnu par rsync comme une expression régulière. Et rien ne semble fonctionner pour Subversion, pour lequel vous devriez analyser .svn/dir-prop-base pour une copie de travail 1.6 ou antérieure, et levez les mains en signe de consternation pour une copie de travail 1.7 ou ultérieure.

4voto

Shawn Wang Points 641

Essayez ça :

rsync -azP --delete --filter=":- .gitignore" <SRC> <DEST>

Il peut copier tous les fichiers dans le répertoire distant, à l'exception des fichiers dans '.gitignore', et supprimer les fichiers qui ne sont pas dans votre répertoire actuel.

3voto

ffeast Points 6645

Pour mercuriel vous pouvez utiliser

hg status -i | sed 's/^I //' > /tmp/tmpfile.txt

pour collecter la liste des fichiers qui ne sont PAS sous le contrôle de mercurial à cause de .hgignore restrictions et ensuite exécuter

rsync -avm --exclude-from=/tmp/tmpfile.txt --delete source_dir/ target_dir/

pour rsynchroniser tous les fichiers sauf ceux qui sont ignorés. Avis -m dans rsync qui exclura les répertoires vides de la synchronisation parce que hg status -i ne listerait que les fichiers exclus, pas les répertoires

3voto

rfcreader Points 361

J'avais un certain nombre de très grandes .gitignore et aucune des solutions "rsync pur" n'a fonctionné pour moi. J'ai écrit ceci wrapper rsync script il respecte pleinement .gitignore règles (y compris ! -et les exceptions de style .gitignore dans des sous-répertoires) et a fonctionné à merveille pour moi.

1voto

druid62 Points 87

Alternatives :

git ls-files -zi --exclude-standard |rsync -0 --exclude-from=- ...

git ls-files -zi --exclude-per-directory=".gitignore" |...

(rsync ne comprend que partiellement .gitignore)

1voto

luksan Points 11

Consultez la section MERGE-FILES FILTER RULES dans rsync(1).

Il semble qu'il soit possible de créer une règle rsync --filtre qui inclura les fichiers .gitignore lors du parcours de la structure du répertoire.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X