131 votes

Passer de CVS à Git : $Id$ équivalent ?

J'ai lu un certain nombre de questions concernant des outils simples de contrôle du code source et Git m'a semblé être un choix raisonnable. Je l'ai mis en place et il fonctionne bien jusqu'à présent. Un aspect que j'apprécie dans CVS est l'incrémentation automatique d'un numéro de version.

Je comprends que cela a moins de sens dans un dépôt distribué, mais en tant que développeur, j'ai envie/besoin de quelque chose comme ça. Laissez-moi vous expliquer pourquoi :

J'utilise Emacs. Périodiquement, je cherche de nouvelles versions des fichiers sources Lisp pour des paquets tiers. Disons que j'ai un fichier, foo.el, qui, d'après l'en-tête, est la version 1.3 ; si je cherche la dernière version et que je vois qu'elle est 1.143 ou 2.6 ou autre, je sais que je suis loin derrière.

Si, au lieu de cela, je vois deux hachages de 40 caractères, je ne saurai pas lequel est le plus récent et je n'aurai aucune idée de l'ampleur de ce retard. Je détesterais devoir vérifier manuellement les ChangeLogs juste pour avoir une idée de mon retard.

En tant que développeur, je tiens à faire preuve de courtoisie à l'égard des personnes qui utilisent mes produits (et peut-être que je me fais des illusions à ce sujet, mais laissons cela de côté pour l'instant). Je ne veux pas avoir à me rappeler d'incrémenter moi-même ce foutu nombre à chaque fois, ou un horodatage ou quelque chose comme ça. C'est une véritable plaie, et je le sais d'expérience.

Quelles sont donc les alternatives qui s'offrent à moi ? Si je ne peux pas obtenir d'équivalent en $Id:$, comment puis-je fournir ce que je cherche ?

Je dois préciser que je m'attends à ce que l'utilisateur final n'ait PAS installé Git et, même s'il l'a fait, qu'il ne dispose pas d'un dépôt local (en effet, je m'attends à ce qu'il ne soit pas disponible de cette manière).

68voto

Dustin Points 35205

Le CSA n'est qu'une représentation d'une version (bien que canonique). Le git describe commande en offre d'autres et le fait très bien.

Par exemple, lorsque je lance git describe dans la branche principale de mon Client Java memcached source, j'ai compris :

2.2-16-gc0cd61a

Cela signifie deux choses importantes :

  1. Il y a eu exactement 16 modifications dans cet arbre depuis la version 2.2.
  2. Les exactes L'arbre des sources peut être affiché sur le clone de quelqu'un d'autre.

Supposons, par exemple, que vous ayez emballé un version avec la source (ou même réécrit tout le contenu pour la distribution) pour montrer ce numéro. Supposons que la version packagée soit 2.2-12-g6c4ae7a (pas une version, mais une version valide).

Vous pouvez maintenant voir exactement à quel point vous êtes en retard (4 commits), et vous pouvez voir exactement quels sont les 4 engagements :

# The RHS of the .. can be origin/master or empty, or whatever you want.
% git log --pretty=format:"%h %an %s" 2.2-12-g6c4ae7a..2.2-16-gc0cd61a
c0cd61a Dustin Sallings More tries to get a timeout.
8c489ff Dustin Sallings Made the timeout test run on every protocol on every bui
fb326d5 Dustin Sallings Added a test for bug 35.
fba04e9 Valeri Felberg Support passing an expiration date into CAS operations.

1 votes

L'utilisation de cette méthode échouera car vous fusionnez la branche de développement, alors que la branche principale contient des correctifs. Le nombre de commits depuis la dernière version changera. Le hash n'est pas fiable car quelqu'un peut reconstruire l'ensemble avec filter-branch ou quelque chose comme ça.

0 votes

L'article ne décrit que l'apprentissage de l'information, et non son intégration dans votre exécutable. Pour cela, vous devez exécuter le programme git describe juste avant de compiler, de sauvegarder la sortie dans un fichier d'en-tête ou d'intégrer la valeur dans votre code.

57voto

Sebastian Pipping Points 347

Git supporte désormais $Id:$. Pour l'activer pour les fichiers LISEZ-MOI vous mettriez "README ident" dans .gitattributes . Les caractères génériques dans les noms de fichiers sont pris en charge. Voir man gitattributes pour plus de détails.

14 votes

Cela vous donne le sha1 du blob, mais pas le sha1 du commit. Utile, mais pas en tant qu'identifiant du commit.

4 votes

Git n'a pas de mécanisme d'expansion des mots-clés comme le programme $Id$ mentionnés. Ce qui est stocké est exactement ce que vous obtenez. Dans tous les cas, la version appartient à l'ensemble des fichiers composant un commit, et non à un fichier en particulier (cette idée est un vestige de l'époque RCS, ou peut-être que c'est le SCCS qui est à blâmer ici...). Comme CVS n'est qu'une façade glorifiée de RCS, et que SVN essaie d'être un CVS-workalike, c'est resté).

33voto

Imran-UK Points 131

Cette demande n'est pas déraisonnable de la part de l'OP.

Mon cas d'utilisation est le suivant :

  1. J'utilise Git pour mon code personnel, donc pas de collaboration avec d'autres.
  2. J'y conserve des scripts du système Bash qui pourraient aller dans /usr/local/bin lorsqu'ils sont prêts.

J'utilise trois machines distinctes avec le même dépôt Git. Il serait intéressant de connaître la "version" du fichier que j'ai actuellement dans le dépôt Git. /usr/local/bin sans avoir à faire un "diff -u <version de la réexploitation> <version dans /usr/local/bin>" manuel.

Pour ceux qui sont négatifs, n'oubliez pas qu'il existe d'autres cas d'utilisation. Tout le monde n'utilise pas Git pour le travail collaboratif, les fichiers dans le dépôt Git étant leur emplacement "final".

Quoi qu'il en soit, la façon dont j'ai procédé a été de créer un fichier d'attributs dans le référentiel comme suit :

cat .git/info/attributes
# see man gitattributes
*.sh ident
*.pl ident
*.cgi ident

Placez ensuite $Id$ quelque part dans le fichier (j'aime le placer après le shebang).

L'engagement. Notez que cela ne fait pas automatiquement l'expansion comme je m'y attendais. Vous devez recopier le fichier, par exemple,

git commit foo.sh
rm foo.sh
git co foo.sh

Ensuite, vous verrez l'expansion, par exemple :

$ head foo.sh
#!/bin/sh

# $Id: e184834e6757aac77fd0f71344934b1cd774e6d4 $

De bonnes informations sont disponibles dans Comment activer la chaîne d'identification pour un dépôt Git ? .

3 votes

Il convient de noter que cela permet d'identifier l'actuelle fichier (blob), et non le commit actuel

3 votes

Qu'est-ce que git co censé faire ? J'ai obtenu le message d'erreur " git: 'co' is not a git command. See 'git --help'. " Doit qu'il soit git checkout ?

0 votes

@peter : co est juste un alias : par exemple git config --global alias.ci commit ; git config --global alias.st status ; git config --global alias.co checkout.

23voto

orip Points 28225

Il n'est pas certain que cela se fasse un jour dans Git. Pour quote Linus :

"La notion de substitution de mots-clés est totalement idiote. Il est trivial à faire "en dehors" du suivi du contenu réel, si l'on veut l'avoir lorsque l'on fait des arbres de diffusion comme des tar-balls, etc.

Il est cependant assez facile de vérifier le journal - si vous suivez la branche stable de foo.el, vous pouvez voir quels sont les nouveaux commits dans le journal de la branche stable qui ne sont pas dans votre copie locale. Si vous voulez simuler le numéro de version interne de CVS, vous pouvez comparer l'horodatage du dernier commit.

Edit : vous devriez écrire ou utiliser les scripts de quelqu'un d'autre pour cela, bien sûr, et non pas le faire manuellement.

30 votes

Oui, j'ai lu une partie de cette longue série d'e-mails sur les extensions de mots clés. L'attitude de Linus a presque suffi à me faire abandonner complètement git.

15 votes

Oui, il manque parfois de politesse, mais il est généralement correct, et il l'est certainement sur le sujet de l'expansion des mots-clés.

1 votes

Le suivi des versions est nécessaire. git est utilisé dans bien d'autres infrastructures que le développement pur, où l'on peut lire le code pour déterminer s'il a du sens. Mais lorsqu'un système de contrôle de révision est utilisé pour suivre des fichiers au contenu arbitraire, il faut disposer d'un moyen de connaître la version officielle. git, sans parler de git log, n'est pas sur la machine sur laquelle les fichiers .ini, .conf, .html et autres ont été poussés.

21voto

Bombe Points 34185

Comme je l'ai écrit avant :

Il est impossible d'avoir des étiquettes Id générées automatiquement qui indiquent un numéro de version raisonnable avec des outils DSCM comme Bazaar parce que la ligne de développement de chacun peut être différente de toutes les autres. Ainsi, quelqu'un peut se référer à la version "1.41" d'un fichier, mais votre version "1.41" de ce fichier est différente.

En fait, $Id$ n'a aucun sens avec Bazaar, Git et d'autres outils de gestion de code source distribué.

7 votes

C'est vrai, j'ai lu cela avant de poster, et c'est pourquoi j'ai demandé une solution plus générale au problème sous-jacent. Je pense que le désir qu'un fichier individuel ait un numéro de version est légitime, tout comme l'est l'incapacité de git à fournir une solution.

0 votes

Ce n'est pas une incapacité de Git, c'est une incapacité de tous les SCM distribués. Si vous voulez vraiment des numéros de version significatifs, utilisez Subversion, ou CVS, ou un autre système centralisé.

0 votes

Vous avez raison, j'aurais dû dire "tout comme l'incapacité du DSCM à fournir une solution".

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