J’ai reçu une notif m’invitant à participer à ce groupe de travail, et en regardant de plus près, j’ai vu qu’il s’appelait IndexErrorCoders.

Après investigation, il est né d’une question sur IndexError qui, commentaire après commentaire, à abouti à la création d’un repo git dédié aux design patterns Python.

C’est toujours sympas de voir les trucs qui se forment autour de notre petite communauté, on a l’impression de vivre dans une coloc avec tout le monde :)

Bonne chance au projet.

git checkout --track nom_du_remote/nom_de_la_branche

Par exemple :

git checkout --track origin/dev

Ce qui va avoir pour effet de créer une branche “dev” sur votre repo local, de vous switcher dessus, et la lier à la branche “dev” du remote “origin”.

Comme d’hab, assurez-vous que votre copie de travail est bien propre avant sinon ça va merder au moment de changer de branche.

Ouais, ouais, je sais, checkout est la commande fourre-tout de git qui fait absolument n’importe quoi. C’est relou.

ATTENTION, CECI EST UNE OPERATION DANGEREUSE.

git filter-branch -f --index-filter "git rm -r --cached --ignore-unmatch chemin/vers/fichier" --prune-empty --tag-name-filter cat -- --all

Si le fichier a été dans plusieurs endroits durant sa vie, il faut relancer la commande pour chaque chemin.

Puis :

git push remote branch --force

Cette seconde commande est à lancer pour chaque branche et chaque tag concerné.

Comme tout ce qui change l’historique, il faut que tous les autres repos appliquent aussi cette opération.

Tous vos collègues devront, soit appliquer eux aussi “filter-branch”, soit faire un rebase de toutes les branches basées sur celles modifiées par vous.

La commande peut prendre pas mal de temps à tourner. L’opération totale avec syncro entre collègues, je ne vous en parle pas. Et si vous foirez une étape, je vous garantis que ça va être la merde.

Mais c’est possible, en cas d’extrême urgence.

Pour se simplifier la tâche, il existe un petit soft spécialisé pour ça qui est bien plus rapide et avec moins de risques.

Mais ça reste dangereux, donc mollo.

Use case typique : on a merdé les derniers commits, et on veut oublier tout ce qu’on a fait et retourner à l’état d’il y a x commits précédents.

Par exemple, là je veux revenir à mon commit 85711ad... :

commit 093bab5aa9d41f580037d51421b7c5d0db73e2ce
Author: sam 
Date:   Sat Jun 28 09:37:55 2014 +0700

    Ok, c'est la merde internationale

commit 0b768f1c0e37a6141e6cd4c472eb3f369f4334d7
Author: sam 
Date:   Sat Jun 28 09:37:36 2014 +0700

    Je commence à merder

commit 85711ad1e8c54f3fd3048d405addef48921e90fd
Author: sam 
Date:   Sat Jun 28 09:37:20 2014 +0700

    J'adore ce commit

Il y a plein de manières de faire, et on voit sur la toile beaucoup de solutions à base de checkout et de reset. La plupart sont dangereuses ou ont un résultat inattendu, présuppose un état de votre repo ou va vous mettre dans une situation que vous ne maîtrisez pas.

Devinez quoi ? Il y a plus simple, et plus propre.

Etape 1: avoir une copie de travail propre

Avant d’inverser des commits, assurez vous que votre copie de travail est nette. Pas de fichiers modifiés en attente d’être commités. Le moins de fichiers non trackés par git possible (idéalement zéro, soit c’est commité, soit c’est dans le .gitignore).

Si vous avez des fichiers modifiés, vous pouvez soit les mettre de côté temporairement avec git stash, soit annuler toutes les modifications avec git reset --hard HEAD. Attention, cette dernière commande n’est pas réversible et va mettre à plat votre copie de travail pour qu’elle soit l’exacte copie du dernier commit de votre histo.

Etape 2

???

Etape 3: profit !

git revert --no-commit 85711ad1..HEAD

Ceci va modifier la copie de travail (donc les fichiers que vous avez sur le disque dur en direct, pas l’histo git) en appliquant des patchs qui contiennent les différences entre HEAD et le commit avec ce hash.

En clair : vos fichiers vont être dans l’état dans lequel ils étaient à ce commit. En prime, l’index est mis à jour.

Vous pouvez alors faire les derniers ajustements que vous le souhaitez. Il faut ensuite finaliser la procédure par un commit avec un message significatif :

git commit -m "Abort ! Abort ! Inversion des 2 derniers commits, retour à 85711a"

Si vous aviez fait un stash, c’est le moment de faire un stash apply derrière.

Maintenant, si vous matez l’histo, vous verrez qu’on n’a pas effacé les commits précédents, on a juste fait un commit qui inverse tout ce qu’ils avaient fait :

commit 03e55de36ad29a26a461874988d4066ebf6fe6be
Author: sam 
Date:   Sat Jun 28 09:43:32 2014 +0700

    Abort ! Abort ! Inversion des 2 derniers commits, retour à 85711a

commit 093bab5aa9d41f580037d51421b7c5d0db73e2ce
Author: sam 
Date:   Sat Jun 28 09:37:55 2014 +0700

    Ok, c'est la merde internationale

commit 0b768f1c0e37a6141e6cd4c472eb3f369f4334d7
Author: sam 
Date:   Sat Jun 28 09:37:36 2014 +0700

    Je commence à merder

commit 85711ad1e8c54f3fd3048d405addef48921e90fd
Author: sam 
Date:   Sat Jun 28 09:37:20 2014 +0700

    J'adore ce commit

Ce qui évite bien des problèmes : pas de réécriture de l’histo, possibilité de récupérer du code dans les commits inversés plus tard, claire indication de ce qui s’est passé…

N’oubliez pas que souvent, revenir à un commit précédent est overkill. Il est généralement beaucoup plus simple de juste récupérer un ou deux fichiers dans l’état de l’époque avec :

git checkout [hash] -- chemin/vers/fichier

[diff]
    tool = kdiff3
	keepBackup = false
	prompt = false
[merge]
    tool = kdiff3
	keepBackup = false
	prompt = false
[mergetool "kdiff3"]
    path = C:/Program Files (x86)/KDiff3/kdiff3.exe
    trustExitCode = false

Remplacez “C:/Program Files (x86)/KDiff3/kdiff3.exe” par le bon chemin selon votre système, bien entendu.

kdiff3 a tendance à laisser trainer des fichiers *.orig après le merge, et ça peut se régler dans Configure/Options > Directory Merge > Backup Files (*.orig).

Ainsi votre prochain merge ouvrira tranquilement kdiff3 pour chaque conflit.

Trouver une bonne formation, c’est pas évident. Donc je me dis qu’il faudrait que j’ai une page sur le site avec un listing de bonnes adresses. Le truc, c’est que je ne peux pas vraiment le faire à partir d’adresses que je connais, car mes clients me grilleraient dans la seconde.

Donc voilà le plan :

Si vous avez fait une formation Python / Django / Git (et rien d’autre) dont vous avez été satisfait, donnez en commentaire le site de l’entreprise ou du formateur indépendant avec qui vous l’avez faite. Ajoutez un petit texte d’explication sur le sujet de la formation, la date, la durée et une appréciation. Sans ça on ignorera le commentaire. Il n’y a PAS de limite de zone géographique.

Si vous êtes un formateur INDEPENDANT (pas un organisme de formation ou une grosse boîte Python), mettez un lien vers votre site Web afin qu’on vous donne un petit coup de pouce. Si vous n’avez pas de site ou êtes limités à une zone géographique, ajoutez des précisions. Précisez aussi si vous acceptez le DIF.

Une fois que j’aurais quelques liens, je ferai une page permanente sur le site qui va permettre à ceux qui cherchent de tomber sur des bonnes formations. Et ceux qui sont des petits formateurs pourront bénéficier un peu de notre ref, car je sais que c’est pas facile pour eux.

Attention, si vous faites partie d’un organisme de formation et que vous essayez de tricher en vous faisant passer pour un client, vous prenez un risque. Si vous vous faites choper, on fera en sorte que toute la communauté Python française sache que vous êtes des connards. A bon entendeur…

Si vous avez un doute sur le fait que vous soyez acceptable ou pas dans le listing, postez un commentaire avec la question, on ne vous mordra pas. Vouloir un lien vers son site n’est pas un crime.

On ne mettra pas d’organisme de formation, ou de société spécialisée dans le Python qui fait aussi des formations, sous prétexte qu’ils ont bonne réputation. Par exemple : Logilab est une très belle société Python pour laquelle j’ai beaucoup de respect. Mais si personne ne donne un témoignage de formation avec eux, je ne les mettrai pas dans le listing. De toute façon je pense qu’ils n’en ont pas besoin :)

Vous avez tout à fait le droit de demander à un de vos anciens clients de venir exprès poster sur le site pour apparaitre dans le listing. Un client satisfait reste un client satisfait.

Il n’y a pas de limite de temps, si vous revenez dans 6 mois pour poster un truc ici, je mettrai la liste à jour.

Ça sent le vécu n’est-ce pas ?

Mais bien entendu git vient avec une option bien cachée au fond de son fion pour adresser ce problème :

git config credential.helper 'cache --timeout=3600'

Et votre authentification sera gardée en mémoire pour une heure. Vous pouvez faire :

git config --global credential.helper 'cache --timeout=3600'

Pour l’étendre à tous les repos de votre machine.

Bien entendu, le Mac wifi est annoncé comme “Internet gratuit Illimité”, ce qui en langage commercial ignorant signifie une partie du Web censurée et les ports de emails ouverts si vous nous achetez un maxi best of.

Donc pas de SSH.

Heurement Github est grand, Github est beau, et Github accepte les push via HTTPS.

Modifiez juste une ligne dans votre fichier .git/config de :

[remote "origin"]
	url = git@github.com/votre_pseudo/votre_repo.git

Vers :

[remote "origin"]
	url = https://github.com/votre_pseudo/votre_repo.git

La commande git devrait vous prompter pour username (mettez votre email) et mot de passe, et hop : le monde du télétravail à la campagne s’ouvre à vous.

C’est un fichier vide, nommé, comme vous pouvez l’imaginer, .gitkeep, et que l’on met dans chaque dossier que l’on veut garder. On ajouter le fichier à l’index, et on commit. Dès que le dossier n’est plus vide, on supprime le fichier .gitkeep, et on le commit.

Cependant on veut parfois garder un dossier vide, et qu’il n’y ait jamais de fichier dedans, comme par exemple le dossier /static/ de Django si vous distribuez un software à base de ce framework, puisqu’il doit servir à vos utilisateurs pour y mettre leurs fichiers statiques plus tard. Il serait donc embêtant de mettre un fichier dedans par erreur et le commiter.

Pour éviter cela, il suffit de créer un fichier .gitignore dedans, et de lui donner ces règles :

*           # git ignore tous les fichiers
!.gitignore # sauf celui-ci

Ce qui aura pour effet d’interdire le moindre ajout de fichier du dossier en question dans Git, à part le .gitignore, évidement.

Ici on me demandais (je crois ^^) comment faire pour donner un lien de téléchargement d’un code sous Gitub. Voici l’info, si ça vous intéresse.

Sur github, tu peux sans problème donner un zip à télécharger, tant que
ton repository est publique.

Par exemple, notre lib batbelt est à l’URL github :

https://github.com/sametmax/Bat-belt/

Il suffit de rajouter :

archive/master.zip

Et c’est téléchargeable :

https://github.com/sametmax/Bat-belt/archive/master.zip

En plus ce sera toujours la dernière version. Ca marche pour toutes les
branches et tous les tags, mais aussi n’importe quel commit :

https://github.com/sametmax/Bat-belt/archive/96ca096bb9eead0675186b36c576251935e96cf9.zip

Pour avoir un fichier en particulier, il faut prendre l’URL du fichier,
et la préfixer de “raw” et retirer “blob”. Par exemple, le fichier :

https://github.com/sametmax/Bat-belt/blob/master/batbelt/structs.py

Est téléchargeable à :

https://raw.github.com/sametmax/Bat-belt/master/batbelt/structs.py

Là le fichier est accessible directement, et téléchargeable avec Ctrl + S.

@+

Alala, qu’est-ce que ne ferais pas un blogger pour ajouter du contenu à son blog en en branlant le moins possible ?