Git next et Git prev, pour vos tutos 16


Il peut être pratique de fournir un repository Git plein de code à télécharger dans un tuto. Parfois le code a plusieurs états, comme autant d’étapes que vous voulez que le lecteur découvre au fur et à mesure.

Voici un petit alias Git qui permet de faire exactement cela. Mettez dans votre fichier ~/.gitconfig :

[alias]
    prev = checkout HEAD^1
    next = "!sh -c 'git log --reverse --pretty=%H master | awk \"/$(git rev-parse HEAD)/{getline;print}\" | xargs git checkout'"

Et votre lecteur pourra juste faire :

git next
git prev

Pour passer au commit suivant ou précédent dans votre repo, comme un wizard. Vous pouvez alors dans votre tuto parler du code dans un état donné, puis lui demander de faire git next, puis parler du nouvel état du code, etc.


Leave a comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

16 thoughts on “Git next et Git prev, pour vos tutos

  • Morgotth

    Super cette astuce !
    Même si les dépots git liés à des tutos n’ont parfois qu’un seul commit “First commit”

  • Sam Post author

    @JeromeJ : je me tate à faire un bon tuto sur la question. Mais c’est looooooooooooooooooooooong.

  • Christophe De Saint Léger

    Ha ce Git!! l’outil du siècle :)

    Mais comment faites-vous pour écrire autant de tutos, d’articles !! vous avez un débit impressionnant, et de qualité en plus :p

    Avouez, vous n’êtes pas humains :p
    Bonne continuation .
    Ch.

  • Sam Post author

    On est des bots codés avec des chaînes de markov calibrées sur le site du zéro.

  • roro

    Hey Sam, toi qui est prof, aurait-tu quelque chose à dire ? Sur le thème: Apprentissage par le cours magistral, versus apprentissage par l’exemple. Caractéristiques, singularités. Qu’est-ce qu’un exemple?

  • Sam Post author

    @roro : non j’ai rien a dire sur la question qui n’ai pas déjà été dit et redit.

  • roro

    @Sam : Qui me dit: ” Non j’ai rien a dire sur la question qui n’ai pas déjà été dit et redit.”
    Normal. C’est pour cela que pour homologuer un nouveau système de freinage il faut passer par les essais sur route.
    Pour être plus clair: Je vais à l’article: “Comment améliorer la communauté python francophonne”.
    Là, je fais un copié/collé dans le bloc-note de Windoze, de:
    1)- “Le bout de code de Guido VR”, et
    2)-“Le mème bout commenté par Max”.
    J’ouvre le shell, j’y colle le premier: ça marche; j’y colle le deuxième, ça marche pas. (indentation)
    Tout ça pour dire, que l’exemple “véritable” est la meilleure, (je n’ose pas dire la seule) façon de valider un code.
    D’où la question: qu’est-ce qu’un exemple ?

  • roro

    Et bien c’est simple; c’est un truc qui donne la preuve que le code fonctionne.
    D’où la nécessité de disposer d’une sorte de banc d’essai réutilisable,dans lequel on pourra inclure un bout de code et tester son fonctionnement.
    Ce “banc” pouvant de plus, servir de base de départ à des projets, quitte à en élaguer l’inutile.
    Il y a longtemps que je me suis bricolés de tels bancs ( mais ils sont dans un langage dont la seule évocation est honteuse, pour les élites de la prog.)

  • Sam Post author

    Ca exclue le pseudo code, le cas d’école, l’idée théoerique en général. Le problème avec cette idée c’est qu’elle exclude les cas complexes qui ne peuvent pas se représenter par un simple snippet applicable. Il nie aussi la relation qu’il y a entre plusieurs bouts de code, qui peut être ce que l’exemple veut illustrer.

    C’est pour ça que je n’ai pas voulu me risquer à répondre cette question, c’est parceque je ne pense pas pouvoir y répondre sans dire une contre vérité.

  • roro

    Et c’est pourquoi, je ne développe pas en python à partir de zéro.
    Je préfère bricoler sur des codes existants, et fonctionnels, même si ce sont parfois des trés gros morceaux.
    Comme le code fonctionne, je peux tester mes modifs, “in situ”.
    Parce qu’en prog, on a beau savoir ce qu’on fait, on fini toujours, à un moment, par avancer à l’intuite”, et c’est là que les soucis commencent.

  • roro

    Un banc d’essais peut être simple, complexe, ou non réalisable; en fonction de ce qu’on a à tester.
    Et vu la poly(morphie!?!) du python, de tels bancs ne sont pas évidents à concevoir.
    Cela reste un bel exercice d’imagination.