Archives des mots-clés : Git

Subversion ne gère pas les étiquettes de la même manière que Git. C’est pour cette raison que suite à une importation je me retrouve souvent à devoir faire des modifications à mon historique. Une étiquette créée lors d’une importation est composée d’une soumission sur laquelle une étiquette légère est ajoutée. Ce que je veux, c’est une étiquette annotée sans l’ajout d’une soumission inutile. Dans cet article, nous allons voir comment faire cela. Il est important de mentionner que les lignes de commandes mentionnées plus bas ont un impact sur votre historique. Faites attention de bien les comprendre avant de les utiliser.

Utilisez cette commande pour voir quelles étiquettes doivent être changées:

git for-each-ref --sort=-refname --format '%(refname:short) %(taggerdate:iso-local)' refs/tags

S’il n’y a pas de date à coté de la version, c’est que l’étiquette doit être modifiée. Par exemple, ici les versions 3.2.x à 3.4.x doivent être modifiées:

v3.7.0 2019-11-14 12:14:06 -0500
v3.6.1 2019-05-09 12:43:48 -0400
v3.6.0 2017-11-09 15:33:19 -0500
v3.5.0 2017-06-13 18:18:37 -0400
v3.4.0
v3.3.1
v3.3.0
v3.2.4
v3.2.3
v3.2.2
v3.2.1
v3.2.0

Dans l’image suivante on peut confirmer que c’est effectivement la vérité. Les dates affichées sont celles des étiquettes annotées uniquement, ce qui n’est pas le cas pour l’étiquette légère v3.4.0.

La nouvelle étiquette doit conserver la date de la soumission 72dce852, car c’est à cette date que la relâche a normalement eu lieu. Dans l’image précédente on peut voir que la dernière soumission pour la relâche a été effectuée au mois de mai. Par contre, l’étiquette a été créée au mois de juin. Utilisez la commande suivante pour récupérer la bonne date:

git log --tags --simplify-by-decoration --date=iso-local --pretty="format:%ad %d"

Voici un exemple de ce que j’obtiens:

2019-10-30 17:46:26 -0400  (tag: v3.7.0)
2019-04-25 19:54:37 -0400  (tag: v3.6.1)
2017-11-08 18:25:32 -0500  (tag: v3.6.0)
2017-06-13 17:31:05 -0400  (tag: v3.5.0)
2016-06-23 15:35:04 -0400  (tag: v3.4.0)
2015-02-18 17:04:22 -0500  (tag: v3.3.1)
2014-12-08 09:59:58 -0500  (tag: v3.3.0)
2012-07-03 10:26:33 -0400  (tag: v3.2.4)
2012-03-13 17:07:43 -0400  (tag: v3.2.3)
2011-12-20 15:12:39 -0500  (tag: v3.2.2)
2010-12-20 16:07:02 -0500  (tag: v3.2.1)
2010-09-10 16:55:17 -0400  (tag: v3.2.0)
2005-08-02 11:20:49 -0400

Cette commande donne la date de la dernière soumission effectuée avant l’étiquette et non la date de l’étiquette. C’est pourquoi cette commande nous sert pour les étiquettes non conformes. Maintenant, pour créer la nouvelle étiquette, on fait une commande similaire à celle-ci:

GIT_COMMITTER_DATE="2016-06-23 15:35:04 -0400" \
  git tag --annotate v3.4.0 \
    --message="Tag the 3.4.0 release" \
    d4ac586497b0642152fde2c682984bfbfe453113

À la première ligne, vous devez mettre la date de l’étiquette. La deuxième ligne sert à spécifier le nom de l’étiquette annotée. La troisième ligne est le message de l’étiquette. Finalement, la quatrième sert à désigner la dernière soumission sur laquelle l’étiquette est attachée. Lorsque que la commande est exécutée, il est possible d’avoir une erreur si vous tentez de créer une étiquette qui existe déjà. Alors, il suffit de supprimer l’étiquette existante et de réessayer la commande.

Comme on peut le voir dans l’image précédente, la soumission inutile a été supprimée et une étiquette annotée a été créée à la date de l’ancienne étiquette. Donc l’historique est complètement conservé.

Si une étiquette du même nom existe sur le serveur, vous devez d’abord la supprimer avec cette commande et ensuite vous pourrez pousser la nouvelle:

git push --delete origin v3.4.0

Il suffit maintenant de répéter ces étapes pour chaque étiquettes. J’espère pour vous qu’elles ne sont pas trop nombreuses. Sinon, il y a toujours moyen de vous simplifier la vie en générant toutes vos commandes avec une commande de la sorte:

git log --tags --simplify-by-decoration --date=iso-local \
  --pretty="format:GIT_COMMITTER_DATE=\"%ad\" GIT_COMMITTER_NAME=\"%an\" GIT_COMMITTER_EMAIL=\"%ae\" git tag --annotate v%S --message=\"Tag the %S release\" \$(git log --pretty=%%P -n 1 %H)"

Bonjour, il est facile de faire la migration de Subversion vers Git, car l’outil git svn nous simplifie la vie grandement.

La première étape est de bâtir une liste de correspondance entre les noms utilisés dans Subversion et ceux qui seront utilisés dans Git. Pour cela il faut créer un fichier que je nomme habituellement users.txt et y insérer les auteurs comme suit:

Crayon = Crayon2000 <crayon@serveur.com>
(no author) = Crayon2000 <crayon@serveur.com>

À gauche du symbole « égal », on retrouve le nom utilisé dans Subversion et à droite, c’est celui utilisé dans Git. Si une soumission a été faite sans auteur, il faut utiliser (no author) comme à la dernière ligne. J’avais eu ce problème avec Google Code car la première soumission était faite par le système pour créer la structure standard de dossier.

Une structure standard est la plus facile à cloner, elle ressemble à ceci:

Donc, il s’agit d’une structure de dossier qui contient les dossiers trunk, tags et branches dans le dossier racine. Pour cloner ce genre de structure, on utilise le paramètre –stdlayout comme ceci:

$ git svn clone https://wii-tac-toe.googlecode.com/svn/ \
    --authors-file=users.txt --stdlayout Wii-Tac-Toe

Cette commande simplifie la syntaxe, car on aurait aussi pu utiliser celle-ci:

$ git svn clone https://wii-tac-toe.googlecode.com/svn/ \
    -Ausers.txt --trunk=trunk --tags=tags --branches=branches Wii-Tac-Toe

Si vous clonez un dépôt local sur votre PC, il est important d’enlever le : après le lettre du disque. Donc à la place de file:///C:/repo il faut utiliser file:///C/repo

Les messages créés lors du clonage devraient ressembler à celui-ci:

libpng updated to 1.4.5

git-svn-id: https://wii-tac-toe.googlecode.com/svn/trunk@104 bba1cac1-252d-79fd-420d-80adb1f9fa09

Si vous désirez ne pas avoir la dernière ligne, alors il faut ajouter le paramètre –no-metadata à la ligne de commande.

Maintenant, voyons un autre type de structure que beaucoup de gens utilisent sous Subversion, il s’agit d’une structure dans laquelle les dossiers standards ont étés omis. Donc les fichiers sont enregistrés directement dans le dossier principal. Elle ressemble à ceci:

Pour cloner cette structure, on doit faire ceci:

$ git svn clone https://wii-tac-toe.googlecode.com/svn/ \
    --authors-file=users.txt Wii-Tac-Toe

Il est possible aussi qu’un projet ait été démarré dans une branche, alors la structure ressemble à celle-ci:

Pour cloner cette structure, on doit faire ceci:

$ git svn clone https://wii-tac-toe.googlecode.com/svn/ -Ausers.txt  \
    --trunk=branches/Sub Wii-Tac-Toe

La prochaine structure peut aussi exister si vous avez créé un projet avec la structure standard à l’intérieur d’une branche. Cette structure serait similaire à celle-ci:

Pour cloner cette structure on doit faire ceci:

$ git svn clone https://wii-tac-toe.googlecode.com/svn/ -Ausers.txt  \
    --trunk=branches/Sub/trunk --tags=branches/Sub/tags --branches=branches/Sub/branches Wii-Tac-Toe

Je sais que cette structure n’a rien de standard, mais il m’est arrivé de la faire lorsque je voulais tester une petite application en lien avec celle dans le dossier racine. Par la suite seulement on se rend compte qu’elle devrait être dans son propre dépôt, mais par paresse on ne le fait pas. Il faut prendre cette opportunité lors de la migration vers Git.

Tous les types de clonage que l’on a vus sont assez simples comparativement à celui qui vient. C’est un cas de « j’ai changé d’idée en cours de route ». Il ne s’agit pas d’une structure mais bien de deux. Ceci peut arriver dans les cas où des personnes ont débuté un projet sans la structure standard et qui par la suite ont réalisé que cela n’avait pas de sens. Concrètement, cela veut dire que quelques soumissions ont été faites avec une structure et que par la suite les dossiers trunk, tags et branches ont été créés. Les soumissions fautes dans le dossier de base ont bien sûr été déplacées dans le trunk. Lorsque l’on migre vers Git on ne veut pas perdre l’historique des soumissions qui précèdent la création des dossiers. Donc on cherche à garder le travail dans la structure de gauche et celle de droite:

Pour faire cela, nous allons procéder en deux étapes. La première pour aller chercher les soumissions de la première structure et la seconde pour le reste. Il existe peut-être une façon simple de faire, alors si vous la connaissez n’hésitez pas à laisser un commentaire à cet article.

Pour la première étape, on doit connaitre la soumission qui précède la création de la structure standard. Dans cet exemple, il s’agit de la soumission 38:

$ git svn clone https://wii-tac-toe.googlecode.com/svn/ -Ausers.txt \
    --revision=BASE:38 Wii-Tac-Toe
$ cd Wii-Tac-Toe
$ mv .git/refs/remotes/git-svn .git/refs/remotes/trunk

Pour la deuxième étape, on doit changer la configuration pour utiliser les dossiers de la structure de base. Il faut exécuter ces commandes:

$ git config svn-remote.svn.fetch trunk:refs/remotes/trunk
$ git config --add svn-remote.svn.branches branches/*:refs/remotes/*
$ git config --add svn-remote.svn.tags tags/*:refs/remotes/tags/*

Le fichier .git\config devrait maintenant contenir ces lignes:

	fetch = trunk:refs/remotes/trunk
	branches = branches/*:refs/remotes/*
	tags = tags/*:refs/remotes/tags/*

On va chercher les soumissions dans la structure standard:

$ git svn fetch --revision=BASE:HEAD --authors-file=../users.txt

Au lieu d’utiliser BASE on aurait pu mettre le numéro de la soumission où la structure standard a été créée.
Maintenant on rassemble le tout en mettant le trunk dans le master:

$ git checkout
$ git reset --hard refs/remotes/trunk

Je crois que cela fait le tour des différents types de clones que j’ai effectués jusqu’à maintenant. La tâche n’est pas complétée car il faut faire un peu de ménage et envoyer les données sur le serveur. Voici maintenant les étapes qui s’appliquent à tout ce que l’on a vu précédemment.

Ces lignes servent à aller dans le dossier, si vous n’y êtes pas déjà, et y faire un peu de ménage.

$ cd Wii-Tac-Toe
$ cp -Rf .git/refs/remotes/tags/* .git/refs/tags/
$ rm -Rf .git/refs/remotes/tags
$ cp -Rf .git/refs/remotes/* .git/refs/heads/
$ rm -Rf .git/refs/remotes
$ rm -f .git/refs/heads/trunk

On assigne l’origine:

$ git remote add origin https://github.com/Crayon2000/Wii-Tac-Toe.git

On pousse sur le serveur:

$ git push origin --all
$ git push origin --tags

Si jamais on avait déjà des soumissions et que l’on veut tout effacer et recommencer on peut faire ceci:

$ git push --force --set-upstream origin master
$ git push --force origin --tags

Attention ces commandes vont détruire tout votre historique existant.

Voilà, maintenant je crois que j’ai exposé toutes mes connaissances actuelles sur Git dans cet article. Bonne chance!

Liens intéressants:

• Git et les autres systèmes – Migrer sur Git
• Git and Other Systems – Migrating to Git (version anglaise du lien précédent)
• git-svn

No doubt https://energyhealingforeveryone.com/levitra-7845.html on line cialis those erection problems can happen due to various reasons and for some patients the side effects of these drugs may seen: Antacids: Antacids containing Aluminum and Magnesium are given but contraindicated in documented hypersensitivity, it can’t be safely used in pregnancy as it decreases effect of allopurinol, amprenavir, chloroquine, corticosteroids, diflunisal, digoxin, ethambutol, iron salt, H2 antagonists, isoniazid, penicillamine, phenothiazines, tetracycline, thyroid hormones. Its intake recovers the blood movement in penile area, making male reproductive section stronger. ordine cialis on line check By focusing on what you want and take consistent actions towards it, you’ll be able to end this problem in no time and no longer be troubled by levitra order prescription the question on how to stop premature ejaculation naturally. Nandrolone Decanoate is ideal as a pre-contest anabolic steroid, commonly stacked with Winstrol and with non-aromatizing agents like Halotestin and purchase cialis Trenbolone.