Gérer l'expansion des mots-clés SVN avec git-svn

Question

J'ai récemment posé une question sur expansion de mots-clés dans Git et je suis prêt à accepter la conception de ne pas vraiment soutenir cette idée dans Git.

Pour le meilleur ou pour le pire, le projet sur lequel je travaille en ce moment nécessite une expansion des mots-clés SVN comme ceci

svn propset svn:keywords "Id" expl3.dtx

pour maintenir cette chaîne à jour :

$Id: expl3.dtx 803 2008-09-11 14:01:58Z will $

Mais j'aimerais bien utiliser Git pour faire mon contrôle de version. Malheureusement, git-svn ne le supporte pas, d'après la documentation :

"Nous ignorons toutes les propriétés SVN sauf svn:executable"

Mais il ne semble pas trop difficile de faire émuler ces mots-clés par un couple de hooks pré/post commit. Mais suis-je la première personne à vouloir cela ? Quelqu'un a-t-il du code pour faire cela ?

Answer 1

Ce qui se passe ici : Git est optimisé pour passer d'une branche à l'autre le plus rapidement possible. En particulier, git checkout est conçu pour ne pas toucher aux fichiers qui sont identiques dans les deux branches.

Malheureusement, la substitution des mots-clés RCS casse cela. Par exemple, en utilisant $Date$ exigerait git checkout pour toucher chaque fichier de l'arbre lors du changement de branche. Pour un référentiel de la taille du noyau Linux, cela provoquerait un arrêt brutal.

En général, le mieux est de marquer au moins une version :

$ git tag v0.5.whatever

...et ensuite appelez la commande suivante depuis votre Makefile :

$ git describe --tags
v0.5.15.1-6-g61cde1d

Ici, git me dit que je travaille sur une version anonyme 6 commits après v0.5.15.1, avec un hash SHA1 commençant par g61cde1d . Si vous collez la sortie de cette commande dans un fichier de type *.h quelque part, vous êtes en affaires et vous n'aurez aucun problème à relier le logiciel publié au code source. C'est la manière préférée de faire les choses.

Si vous ne pouvez pas éviter d'utiliser les mots-clés RCS, vous pouvez commencer par ceci explication par Lars Hjemli . En principe, $Id$ est assez facile, et vous si vous utilisez git archive vous pouvez également utiliser $Format$ .

Mais, si vous ne pouvez absolument pas éviter les mots-clés RCS, ce qui suit devrait vous aider à démarrer :

git config filter.rcs-keyword.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
git config filter.rcs-keyword.smudge 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date: `date`\\\$/"'

echo '$Date$' > test.html
echo 'test.html filter=rcs-keyword' >> .gitattributes
git add test.html .gitattributes
git commit -m "Experimental RCS keyword support for git"

rm test.html
git checkout test.html
cat test.html

Sur mon système, j'obtiens :

$Date: Tue Sep 16 10:15:02 EDT 2008$

Si vous avez du mal à obtenir les échappements de l'obus dans le fichier smudge y clean pour fonctionner, écrivez simplement vos propres scripts Perl pour étendre et supprimer les mots-clés RCS, respectivement, et utilisez ces scripts comme filtre.

Notez que vous vraiment Il ne faut pas faire cela pour plus de fichiers qu'il n'est absolument nécessaire, sinon git perdrait une grande partie de sa vitesse.

Answer 2

Malheureusement, le mot-clé RCS casse cela. Par exemple, l'utilisation de $Date$ nécessiterait que git checkout touche tous les fichiers de l'arbre l'arbre lorsqu'il change de branche.

Ce n'est pas vrai. $Date$ etc. s'étendent à la valeur qui existe au moment de l'enregistrement. C'est beaucoup plus utile de toute façon. Ainsi, elle ne change pas sur d'autres révisions ou branches, à moins que le fichier ne soit effectivement re-contrôlé. Extrait du manuel RCS :

   $Date$ The  date  and  time the revision was checked in.  With -zzone a
          numeric time zone offset is appended;  otherwise,  the  date  is
          UTC.

Cela signifie également que la réponse suggérée ci-dessus, avec le filtre rcs-keyword.smudge, est incorrecte. Il insère l'heure et la date de la sortie, ou quoi que ce soit qui provoque son exécution.

Answer 3

Voici un exemple de projet contenant la configuration et le code de filtrage nécessaires pour ajouter le support des mots-clés RCS à un projet git :

https://github.com/turon/git-rcs-keywords

Il n'est pas aussi simple à configurer qu'on le souhaiterait, mais il semble fonctionner. Il utilise une paire de filtres smudge/clean écrite en perl (similaire à ce que la réponse d'emk décrit), et oui, il touchera tous les fichiers avec les extensions définies dans .gitattributes, ralentissant généralement un peu les choses.

Answer 4

Vous pourriez définir l'attribut ident sur vos fichiers, mais cela produirait des chaînes de caractères telles que

$Id: deadbeefdeadbeefdeadbeefdeadbeefdeadbeef$

donde deadbeef... est le sha1 du blob correspondant à ce fichier. Si vous avez vraiment besoin de l'expansion du mot-clé, et que vous en avez besoin dans le repo git (par opposition à une archive exportée), je pense que vous allez devoir utiliser l'option ident gitattribute avec un script personnalisé qui fait l'expansion pour vous. Le problème d'utiliser simplement un hook est qu'alors le fichier dans l'arbre de travail ne correspondrait pas à l'index, et git penserait qu'il a été modifié.