Salut, c'est marrant, j'ai codé la même chose :-) J'ai commencé à écrire scm.py il y a 2 ou 3 ans quand je devais cloner puis mettre à jour une dizaine de dépôts Mercurial au boulot. Ensuite, j'ai ajouté le support de Git car je ne me souvenais jamais si tel projet utilisait git ou mercurial, là j'ai une CLI unifiée pour les commandes les plus courantes. Petit à petit, j'ai ajouté une vingtaine de commandes pour mes besoins :
Comme ça m'est arrivé plusieurs fois de perdre des modifications locales avec git et mercurial, scm.py commence par sauvegarder puis annuler les modifications locales avant les opérations qui modifient le dépôt. Du coup, je ne perds plus jamais mes modifications locales. Si réappliquer les modifications échouent, pas grave, je les ai dans un fichier (.hg/stash, .git/stash) sous forme d'un patch.
J'ai aussi ajouté des avertissements là où git supprime sans crier gare.
Quelques exemples :
scm.py pull : mettre à jour une vingtaine de dépôt git. continue en cas d'erreur : liste les erreurs à la fin. => à utiliser avant de prendre le train/avion sans internet ;-)
scm.py clean : supprime tous les fichiers .pyc, .orig, .swp, etc. récursivement dans les sous-dossiers
scm.py grep PATTERN : c'est tout con, recherche dans tous les fichiers suivi par git/hg (je n'ai jamais compris à quoi sert à la commande "hg grep" :-)), évite de taper "grep PATTERN $(find . -name *.py|grep -v test)" par exemple (d'autres outils comme ack le font, mais je n'installe jamais ack)
scm.py revert : supprime toutes les modifications locales et revient à un état normal (rebase en cours, merge en cours, etc. => hop, annulé)
Bien sûr, scm.py pull et scm.py push utilisent rebase pour garder un historique linéaire !
--
Au passage, j'ai écrit un petit outil par dessus la commande patch : apply_patch.py. C'est tout con : ça devine le paramètre -p pour éviter de mal appliquer un patch, et ça évite évite d'appliquer un patch s'il y a des erreurs (demande confirmation dans ce cas). Ca évite de pourrir un dépôt avec plein de fichiers .bak, .rej, .orig, etc. Je crois que apply_patch.py ne fonctionne pas sous FreeBSD qui malheureusement ne gère pas patch --dry-run.
PS : j'utilise aussi scm.py sous Windows où le shell est plutôt pauvre... (Comment on tape find -name ".orig" -o -name ".rej" -delete sous Windows ? :-p scm.py clean)
--
Ouais, y'a des outils "similaires". Similaires, donc différents. J'ai vraiment "implémenté" ma manière de manipuler le code dans scm.py, donc il me convient parfaitement :-) Et puis je passe peu de temps à le maintenir (qq. heures par mois max). Le plus pénible récemment était de gérer Python 2 et Python 3, ça devraient maintenant être bon ;-) (Ne gérer que l'un ou l'autre n'est pas pratique dans un virtualenv où "python" peut être l'un ou l'autre).
# scm.py et apply_patch.py
Posté par Victor STINNER (site web personnel) . En réponse au journal Gérer son espace de travail git avec "gws". Évalué à 4.
Salut, c'est marrant, j'ai codé la même chose :-) J'ai commencé à écrire scm.py il y a 2 ou 3 ans quand je devais cloner puis mettre à jour une dizaine de dépôts Mercurial au boulot. Ensuite, j'ai ajouté le support de Git car je ne me souvenais jamais si tel projet utilisait git ou mercurial, là j'ai une CLI unifiée pour les commandes les plus courantes. Petit à petit, j'ai ajouté une vingtaine de commandes pour mes besoins :
https://bitbucket.org/haypo/misc/src/tip/bin/scm.py
Comme ça m'est arrivé plusieurs fois de perdre des modifications locales avec git et mercurial, scm.py commence par sauvegarder puis annuler les modifications locales avant les opérations qui modifient le dépôt. Du coup, je ne perds plus jamais mes modifications locales. Si réappliquer les modifications échouent, pas grave, je les ai dans un fichier (.hg/stash, .git/stash) sous forme d'un patch.
J'ai aussi ajouté des avertissements là où git supprime sans crier gare.
Quelques exemples :
Bien sûr, scm.py pull et scm.py push utilisent rebase pour garder un historique linéaire !
--
Au passage, j'ai écrit un petit outil par dessus la commande patch : apply_patch.py. C'est tout con : ça devine le paramètre -p pour éviter de mal appliquer un patch, et ça évite évite d'appliquer un patch s'il y a des erreurs (demande confirmation dans ce cas). Ca évite de pourrir un dépôt avec plein de fichiers .bak, .rej, .orig, etc. Je crois que apply_patch.py ne fonctionne pas sous FreeBSD qui malheureusement ne gère pas patch --dry-run.
https://bitbucket.org/haypo/misc/src/tip/bin/apply_patch.py
PS : j'utilise aussi scm.py sous Windows où le shell est plutôt pauvre... (Comment on tape find -name ".orig" -o -name ".rej" -delete sous Windows ? :-p scm.py clean)
--
Ouais, y'a des outils "similaires". Similaires, donc différents. J'ai vraiment "implémenté" ma manière de manipuler le code dans scm.py, donc il me convient parfaitement :-) Et puis je passe peu de temps à le maintenir (qq. heures par mois max). Le plus pénible récemment était de gérer Python 2 et Python 3, ça devraient maintenant être bon ;-) (Ne gérer que l'un ou l'autre n'est pas pratique dans un virtualenv où "python" peut être l'un ou l'autre).