Git est une forge, c’est-à-dire un outil collaboratif qui permet à des développeuses (ou des développeurs) de travailler sur un projet commun et de le versionner. Ce système, doté de nombreux outils annexes, est très pratique car il permet d’isoler facilement les bugs et de les traiter. Git garde la trace de toutes les modifications. On peut utiliser Git pour développer un logiciel ou pour écrire un roman. Si vous modifiez un chapitre et que trois semaines plus tard, vous avez des regrets, pas de problème! Vous pouvez retrouver la version et ressusciter un personnage qu’entretemps vous avez assassiné pour les besoins de l’intrigue.

En ce qui me concerne, depuis quelques semaines, je l’utilise aussi pour sauvegarder mon répertoire personnel (Documents, Images, etc…). Bien sûr, le dépôt est privé. J’adore Git et je ne vois que des avantages à avoir tout mon répertoire en accès libre partout où je me trouve, pourvu que j’aie une connexion internet. La sauvegarde versionnée est également très intéressante. Cette forge offre en sus, une multitude d’outils très utiles tels que le wiki, les snippets et bien sûr les « issues ». Je n’ai jamais trouvé mon bonheur chez Nextcloud et autres logiciels d’infonuagique. À mon avis, dans ce domaine, Git est ce qui se rapproche le plus de la perfection… ou plutôt de mes attentes.

J’ai écrit un petit script de mise à jour automatisée qui tourne en tâche de fond, au démarrage de l’ordinateur. J’eus préféré qu’il s’exécutât avant l’extinction mais je ne sais pas comment m’y prendre. Voici le script:

#!/bin/bash

# Mise à jour de ma sauvegarde sur git 
cd ~/sauvegarde
git add . 
jour_heure=`date`
git commit -m "Mise à jour du $jour_heure" 
git push -u origin master

# Mise à jour des paquets
tilix -e "sudo pacman -Syu" &

Vous noterez qu’il met également à jour les paquets, mais ce n’est pas l’objet de cet article. Si une modification a été apportée, je le vois tout de suite grâce à la date et à l’heure précises ou elle a été poussée dans le dépôt. C’est très pratique.

Cela dit, je me pose des questions sur l’usage que j’en fait. D’abord au niveau de la sécurité du dépôt. Dans mon répertoire personnel, je n’ai pas de documents classés « secret défense » dérobés lors de mon service militaire et transmis à nos amis les Russes contre une bouteille de vodka par semaine jusqu’à ma mort. Je n’ai pas non plus de mode opératoire pour fabriquer une bombe avec un carburateur de Peugeot 103 relié à une Raspberry Pi. Mais tout de même, ce sont des documents personnels et j’aurais aimé avoir une estimation du niveau de protection de mes données, comparé par exemple à Nextcloud.

Deuxième point qui me turlubite, Git est un outil à vocation collaborative. Il est conçu pour permettre à au moins deux personnes de travailler ensemble. Or, il est difficile de collaborer avec soi-même tout seul! Par conséquent, je n’utilise pas Git de manière réglementaire. Il n’y a rien de collaboratif dans mon dépôt. Ce n’est pas illégal, mais est-ce que c’est moral? Ne suis-je pas en train d’accaparer égoïstement des ressources qui me sont offertes gratuitement et qui seraient utilisées de manière plus judicieuse par des développeuses pour programmer un hackiciel transformant les balles des fusils d’assaut en d’inoffensives pâquerettes? Pour me donner bonne conscience, je me dis que Git est un outil libre et qu’à ce titre, je suis libre de l’utiliser comme bon me semble, mais ça ne répond pas à mes interrogations.

Dans un paragraphe précédent, j’ai écrit que Git est ce qui se rapproche le plus de la perfection. Il y a tout de même quelques menus inconvénients: Primo, mon répertoire personnel ne peut pas contenir un sous-dépôt git. Lorsque ce cas se présente, je ne peux pas le pousser sur mon dépôt de sauvegarde. Secundo, à la création du dépôt, il n’est pas possible de pousser tout son répertoire d’un coup. Une telle action provoque une interruption de la connexion au dépôt distant. Il faut y aller par petites touches, ce qui peut prendre du temps. Ensuite par contre, il n’y a pas de problème pour pousser les mises à jour. Voici un script qui permet d’automatiser le dépôt initial de ses répertoires et fichiers:

#!/bin/bash

# Nom du script: add_images.sh
# Auteur: Benoît
# Fonction: dépôt automatisé de plusieurs répertoires
# Argument $1: Répertoire d'origine

cd ~/sauvegarde
for var_1 in `ls ~/$1`
do
    mkdir ~/sauvegarde/$1/$var_1
    for var_2 in `ls ~/$1/$var_1`
        do 
            mv ~/$1/$var_1/$var_2 ~/sauvegarde/$1/$var_1
            git add ~/sauvegarde/$1/$var_1/$var_2
            git commit -m "Ajout $var_1"
            git push -u origin master
        done
    rm -r ~/$1/$var_1
done

En conclusion, je dirais que la solution de sauvegarder mon répertoire personnel sur une forge est celle qui me convient le mieux car je ne suis pas quelqu’un qui conserve des documents devenus inutiles ou obsolètes. Je balance beaucoup et j’ai donc un volume de données personnelles réduit. Je ne suis pas persuadé que cette méthode convienne à tout le monde. Mais en tout cas, Git me permet d’avoir un outil de sauvegarde performant et d’avoir aussi mon propre nuage. Le problème est que je détourne la forge de son usage initial.

Original post of miamondo.Votez pour ce billet sur Planet Libre.

Aujourd’hui nous allons faire tomber un mythe : la commande git rebase. Non, elle n’est pas compliquée, c’est juste que vous y avez souvent été confrontée dans une situation de stress sans trop comprendre ce qui se passait, par exemple dans un git pull –rebase qui se passe mal. Nous allons étudier un cas simple et vous allez désormais l’utiliser quasiment au quotidien. Oui oui, au quotidien.

Fusion ? Git rebase ?

Si cette partie relativement théorique ne vous intéresse pas, sautez directement au chapitre suivant pour l’exemple pratique.

En prérequis nous allons faire un rappel rapide de ces deux notions. La fusion consiste à prendre les différents commits, à en étudier la possibilité des les assembler et à générer un nouveau commit. D’où le terme de fusion. Vos deux branches d’origine restent inchangées, modulo le nouveau commit créé.

Le rebase fonctionne différemment. Lorsque vous voulez effectuer un rebase, Git va rechercher le commit commun le plus récent entre les deux branches, puis va essayer de constituer une branche cohérente résultante de cette opération.

La grosse différence donc est que dans le cas de la fusion, on obtient le résultat dans un nouveau commit, alors que rebase va retravailler la branche sur laquelle vous êtes.

Cette explication est bien sûr clairement vulgarisée, imparfaite et sommaire, et je vous invite à lire la documentation officielle si vous souhaitez plus de détails.

Entrons dans le vif du sujet avec un cas d’usage que vous rencontrez tous les jours. Croyez-moi.

Le commit imparfait

Cas typique d’usage de rebase : la correction d’un commit imparfait. Vous êtes allé trop vite et avez oublié d’embarquer un fichier dans votre commit, alors vous faites un nouveau commit pour corriger, avec le plus souvent un message peu clair car vous êtes énervé. Ne niez pas, ça nous est tous arrivé et ça vous arrive peut-être encore souvent.

C’est parfait, on va corriger ça avec rebase.

Commençons par mettre l’environnement de test en place avec un nouveau dépôt Git. On passe rapidement sur ces opérations car on en a déjà parlé dans cet article.

$ git init .
Initialized empty Git repository in /home/user/debuter-avec-git/7/.git/
$ echo "foofoofoo" > file1
$ git add file1 
$ git commit file1 -m "initial commit"
[master (root-commit) 9a8a61f] initial commit
 1 file changed, 1 insertion(+)
 create mode 100644 file1

On initie un nouveau dépôt, puis un créé un premier commit avec un fichier file1.

$ echo "barbarbar" > file2
$ git add file2
$ git commit file2 -m "add file2"
[master dcd1b75] add file2
 1 file changed, 1 insertion(+)
 create mode 100644 file2

On ajoute ensuite un deuxième commit, contenant un fichier file2.

La double boulette

Nous voulons maintenant ajouter deux fichiers en même temps au dépôt. Malheureusement pour vous, une réunion commence, vous êtes en télétravail et vous continuez à travailler pendant que votre chef soliloque dans votre casque (on en parle dans cet article). Et là…

$ echo "blablabla" > file3
$ echo "lalalala" > file4
$ git add file3
$ git commit file3 -m "add file3 and file4"
[master 122fa7d] add file3 and file4
 1 file changed, 1 insertion(+)
 create mode 100644 file3

La boulette ! Vous avez oublié d’ajouter le fichier file4 ! Tout ça à cause de la réunion !

$ git status
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)
	file4

Vous tentez de corriger.

$ git add file4
$ git commit file4 -m "azlemjrlmzjaejrlj"
[master 23486d2] azlemjrlmzjaejrlj
 1 file changed, 1 insertion(+)
 create mode 100644 file4

Vous venez en fait d’aggraver la situation. Vous ajoutez à votre première erreur la lourdeur d’un nouveau commit sans réel intérêt et, de plus, un message de commit inutile, sans valeur pour vous et vos collègues. En effet jetons un œil à votre historique avec la commande git log.

$ git log
commit 23486d2a4052710025ea76b6a79ae4a481bef8af (HEAD -> master)
Author: Carl Chenet 
Date:   Tue Mar 2 13:17:59 2021 +0100

    azlemjrlmzjaejrlj

commit 122fa7da505bfd924482dbeb393b1bd64796c874
Author: Carl Chenet 
Date:   Tue Mar 2 13:17:12 2021 +0100

    add file3 and file4

commit dcd1b7500c56025b43172d05d2e071d38544d8e5
Author: Carl Chenet 
Date:   Tue Mar 2 13:15:30 2021 +0100

    add file2

commit 9a8a61f662ea8397f03fdf1b19d45a053dbb83d7
Author: Carl Chenet 
Date:   Tue Mar 2 13:14:33 2021 +0100

    initial commit

On le voit, le dernier commit est, disons-le, laid, sans valeur ajoutée pour personne. Il fait le travail certes mais doit être amélioré, surtout dans le cadre du travail collaboratif où vous n’êtes pas le seul à lire cet historique (voir plus bas). Vous allez faire perdre du temps à tous vos relecteurs.

Git rebase à la rescousse

Nous allons maintenant voir l’intérêt de rebase. Vous passez la commande suivante pour “retravailler” les deux derniers commits.

$ git rebase -i HEAD~2

Cette commande signifie que nous souhaitons appliquer la fonction rebase à partir de HEAD, notre position actuelle sur la branche courante (on en a parlé dans cet article) jusqu’au deuxième commit en arrière.

Un menu apparaît dans votre éditeur qui va vous demander des informations.

pick 122fa7d add file3 and file4
pick 23486d2 azlemjrlmzjaejrlj

# Rebase dcd1b75..23486d2 onto dcd1b75 (2 commands)
#
# Commands:
# p, pick  = use commit
# r, reword  = use commit, but edit the commit message
# e, edit  = use commit, but stop for amending
# s, squash  = use commit, but meld into previous commit
# f, fixup  = like "squash", but discard this commit's log message
# x, exec  = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop  = remove commit
# l, label  = label current HEAD with a name
# t, reset  = reset HEAD to a label
# m, merge [-C  | -c ]  [# ]

# Note that empty commits are commented out

Le haut de ce menu présente une liste des commits qui vont être retravaillés par rebase, les commits sont affichés selon leur ancienneté, de haut en bas (attention, contrairement à git log donc). Tout le reste du fichier est constitué de commentaires à caractère informatif.

Le premier mot précise quelle modification appliquer. Nous allons utiliser le mot-clé fixup pour fusionner le commit désigné avec le précédent, le message de commit du précédent sera également conservé et celui du commit designé sera supprimé. D’une pierre deux coups, donc.

pick 122fa7d add file3 and file4
fixup 23486d2 azlemjrlmzjaejrlj

Nous sauvons maintenant le contenu du fichier.

$ git rebase -i HEAD~2
Successfully rebased and updated refs/heads/master.

Le message annonce que l’opération rebase a été correctement effectuée. Un coup d’œil sur notre historique va nous le confirmer.

$ git log
commit 4fb9e75b8749453936d7cfa409127e228aefdc60 (HEAD -> master)
Author: Carl Chenet 
Date:   Tue Mar 2 13:17:12 2021 +0100

    add file3 and file4

commit dcd1b7500c56025b43172d05d2e071d38544d8e5
Author: Carl Chenet 
Date:   Tue Mar 2 13:15:30 2021 +0100

    add file2

commit 9a8a61f662ea8397f03fdf1b19d45a053dbb83d7
Author: Carl Chenet 
Date:   Tue Mar 2 13:14:33 2021 +0100

    initial commit

Nos deux erreurs ont bien été corrigées. Nous présentons maintenant un commit cohérent, avec un message de commit explicite. Une étude du commit nous le confirme.

$ git show --pretty=oneline 4fb9e75b8749453936d7cfa409127e228aefdc60
4fb9e75b8749453936d7cfa409127e228aefdc60 (HEAD -> master) add file3 and file4
diff --git a/file3 b/file3
new file mode 100644
index 0000000..6a4238f
--- /dev/null
+++ b/file3
@@ -0,0 +1 @@
+blablabla
diff --git a/file4 b/file4
new file mode 100644
index 0000000..854f93c
--- /dev/null
+++ b/file4
@@ -0,0 +1 @@
+lalalala

Les deux fichiers sont bien ajoutés par ce commit désormais unique.

L’utilisation de git rebase dans le cadre du travail collaboratif

Comme nous avons vu, nous aurions pu conserver cette historique et continuer à travailler, mais le problème survient lorsqu’un collègue va vouloir relire l’historique. Si nous n’avions pas corrigé, votre collègue aurait lu azlemjrlmzjaejrlj comme message de commit et aurait donc dû lire lui-même le détail du commit, une opération que l’on peut donc facilement éviter avec un message de commit explicite.

Voyons maintenant comment corriger l’erreur au niveau du dépôt partagé avec les collègues. Nous avions poussé notre double erreur vers le dépôt Gitlab.

$ git push origin master
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 273 bytes | 273.00 KiB/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://gitlab.com/articles/debuter-git-7.git
   9b95c2c..95fe5b2  master -> master

Après notre utilisation du rebase, nous retentons de pousser notre modification.

$ git push origin master
To https://gitlab.com/articles/debuter-git-7.git
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'https://gitlab.com/chaica/debuter-git-7.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Une erreur apparaît. Git nous informe qu’il ne peut pas effectuer l’opération fast-forward, assurant la bonne conduite de la mise-à-jour distante. Il va falloir effectuer une opération un peu plus complexe avec l’option –force-with-lease.

$ git push --force-with-lease origin master
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 8 threads
Compressing objects: 100% (2/2), done.
Writing objects: 100% (4/4), 341 bytes | 341.00 KiB/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To https://gitlab.com/chaica/debuter-git-7.git
 + 95fe5b2...831f45c master -> master (forced update)

Attention. Je ne détaille pas cette option ici mais pour information N’UTILISEZ JAMAIS L’OPTION –force sans être absolument 100% sûr de ce que vous faites et/ou avant d’avoir consulté vos collègues. C’est très souvent une très mauvaise idée. Et presque 100% du temps une bêtise si vous travaillez sur la branche master en collaboration avec d’autres personnes. À éviter donc.

L’option –force-with-lease, contrairement à l’option –-force, va vérifier que le pointeur distant est encore bien positionné sur votre dernier commit précédant le rebase et que tous les pointeurs distants utilisent bien ce commit et donc que quelqu’un d’autre n’a pas retravaillé votre historique, auquel cas vous écraseriez son travail avec –force.

En gros, retenez que vous êtes sûr à 100% de n’impacter personne d’autre avec l’option –force-with-lease de git push quand vous souhaitez pousser votre historique modifié.

Maintenant le retravail de votre historique a bien été poussé sur le dépôt distant, votre commit est bien plus lisible et votre message de commit explicite, prêt à être relu par un collègue.

Le retravail des messages de commits

Il s’agissait ici d’un exemple très simple pour vous initier à la puissance de rebase. Nous n’avons travaillé que sur 2 commits. Vous pourriez en embarquer bien davantage dans votre opération. Vous pouvez même envisager des opérations concernant l’intégralité des commits sur une branche. Boowaa!

Une autre utilisation très classique est le retravail des messages de commits. Nous avons vu – lorsque que rebase vous demande quelle(s) opération(s) vous souhaitez effectuer – que nous avions à notre disposition l’option suivante :

# r, reword  = use commit, but edit the commit message

Vous pouvez donc revenir sur un ou plusieurs messages de commits voire même tous les messages de commits de votre branche, par exemple pour y appliquer un formalisme nécessaire à votre gestionnaire de tickets ou à votre CI/CD. Vous ne pourrez bientôt plus vous en passer, les petites typos que vous avez laissées partout traîner dans vos messages parce que vous ne saviez pas comment les corriger ? Rebase commence à vous plaire, je le sens.

La puissance de git rebase

Notons que nous avons utilisé l’option fixup pour fusionner deux commits pendant l’opération et supprimer le message de celui sur lequel on avait déclaré vouloir effectuer le fixup.

Si vous aviez voulu conserver les deux messages de commits pour les retravailler, vous auriez pu utiliser l’option squash, très couramment utilisée également dans les opérations de rebase.

# s, squash  = use commit, but meld into previous commit

D’autres options plus avancées comme edit ou exec permettent des opérations puissantes et complexes, mais on sort un peu du cadre de l’article. À découvrir donc le jour où vous en aurez besoin

Ceinture et bretelles

N’oubliez jamais que mieux vaut prévenir que guérir.

Avant de tenter une manipulation qui vous semble complexe, n’hésitez pas à copier l’intégralité du répertoire racine qui contient vos sources (celui qui contient le répertoire .git) vers un autre endroit avant d’effectuer votre opération. C’est moche et ça fait rigoler les puristes certes (je vous vois rigoler là au fond) mais ça peut vous éviter bien des ennuis si vous êtes coincé et que personne n’est là pour vous aider. Il faut bien s’entraîner avant de maîtriser, c’est vrai pour tous les outils. Avec une sauvegarde à côté, on ne pourra jamais vous reprocher d’avoir perdu des données.

De plus, bien souvent dans les opérations de rebase qui tournent mal, un simple git rebase –abort vous permet de revenir à l’état antérieur à l’opération.

Conclusion

Nous allons nous arrêter ici pour l’article d’aujourd’hui. Nous avons montré un cas d’utilisation très commun de rebase et comment pousser un historique modifié par rapport à celui qui avait déjà été poussé vers un dépôt partagé.

Je vous encourage à tester rapidement le retravail des messages de commits, c’est également une option dont je me sers assez souvent. Nul doute qu’en maîtrisant ces bases, vous aborderez sereinement les cas d’utilisations plus complexes si un jour vous y êtes confronté.

Finalement et pour rappel, le rebase est une opération puissante et donc comme beaucoup de choses dans Git potentiellement dangereuse, n’hésitez pas à faire une sauvegarde de vos données avant de vous lancer.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre :

• Mastodon : @carlchenet
• Diaspora :  @carlchenet
• Twitter : @carl_chenet

Suivre l’actualité du Logiciel Libre et Open Source francophone

Abonnez-vous au Courrier du hacker, une newsletter hebdomadaire résumant le meilleur de l’actualité francophone du Logiciel Libre et Open Source. Déjà plus de 160 numéros et 3500 abonnés.

[yikes-mailchimp form="1" submit="S'abonner"]

The post Débuter avec Git partie 7 : git rebase pour ré-écrire son historique appeared first on Carl Chenet's Blog.

Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

J'avais migré en Janvier 2013 mon blog vers Pelican en venant de Dotclear. Pelican est un générateur de site statique en Python. J'avais alors dû faire l'impasse sur les commentaires mais au bénéfice d'un site performant et avec une surface d'attaque plus faible.

Plus tard, en décembre 2016, j'avais changé le thème pour alexandrevicenzi/Flex. Aujoud'hui je vais vous montrer la migration de mon blog vers Gridsome.

Je reste sur un générateur de site statique car, j'aime l'idée d'un site à la fois rapide et immuable tant que je ne décide pas de modifier le contenu mon blog. Alors pourquoi changer de Pelican vers Gridsome ?

Gridsome est un générateur de site statique écrit en Javascript. Il a la particularité de pouvoir générer des pages depuis des fichiers au format Markdown mais aussi depuis des CMS Headless, ou de n'importe quelles autres API et ce grace à une API commune en GraphQL.

En plus de générer le site statique au format HTML, Gridsome fonctionne comme une SPA¹. Dans une SPA les pages sont générées côté client et sont mises à jour lors d'appel API pour récupérer les données. Ainsi seul le contenu modifié est rafraichit. Le framework Gridsome se base sur Vue.Js.

Ce qui m'a plus dans Gridsome, c'est l'utilisation de Vue.JS pour générer les pages statiques, mais aussi l'utilisation de GraphQL pour requêter le contenu des pages d'une même et unique façon.

Alternatives

Lors de la migration de mon blog, je voulais une technologie basée sur Vue.Js, car c'est un framework que j'apprécie. Mais le plus important, c'est que j'avais besoin de changement (pour le plaisir quoi ;)).

Les générateurs de site statique en Vue.Js sont :

• VuePress
• Nuxt.js
• Saber
• Gridsome

Je vous laisse regarder et vous faire votre avis sur les différents framework. J'ai surtout testé VuePress mais j'ai changé pour Gridsome quand j'ai vu la simplicité d'implémentation.

Début de l'implémentation

Je voulais changer de technologie, mais j'aimais bien le thème Pelican que j'utilisais. Je n'avais donc pas envie de le changer. Je me suis imposé également les contraintes suivantes:

• Je ne voulais pas changer les différents chemins d'accès au site (tant que faire se peut).

• Je voulais garder les fonctionnalités suivantes:

  • Sitemap
  • Atom
• J'avais des billets écrits en Markdown mais aussi 3 pages que je ne voulais pas réécrire en HTML
• Garder le même thème
• Avoir une page par catégorie et une page avec toutes les catégories
• Avoir une page par tag et une page avec tous les tags

Je commence donc à initialiser un projet de zéro avec mes différents billets de blog, les pages (contact, anciens-projets, et contact) et les fichiers statiques (les images, les zips, ...).

J'ai du retravailler les différents billets de blog au format Markdown:

• J'ai dû déplacer les différents attributs du fichier pour les placer dans un frontmatter au format YAML.

• Les fichiers ont un nom qui porte de l'information. Ainsi, le dossier dans lequel se trouve le fichier constitue le nom de la catégorie, et le nom du fichier porte la date de publication et le slug (utilisé pour le chemin dans l'URL).

  Par exemple, avec le fichier: Logiciels/2009-02-15_debian-lenny-est-sortie.md.

  Avec le changement de paradigme de Gridsome, j'ai dû intégrer ces différentes informations dans le frontmatter.

• J'ai également du retravailler les emplacements de fichiers qui étaient préfixés dans Pelican de |static|/public/.... Dans Gridsome, il n'y pas de syntaxe particulière, juste le nom du fichier absolu.

Avant j'avais:

Title: Debian Lenny est sortie
Tags: debian, kde

![Logo](|static|/public/Logiciels/debian-lenny-est-sortie/debian-logo.png)

et j'ai corrigé cela en

---
title: Debian Lenny est sortie
date: 2009-02-15
tags:
  - debian
  - kde
published: True
category: Logiciels
---

![Logo](/Logiciels/debian-lenny-est-sortie/debian-logo.png)

Afin de pouvoir reprendre mes fichiers au format markdown sans trop de modification, j'ai également installé les plugins remark suivants (ce sur quoi Gridsome se base pour transformer le Markdown en HTML) :

• @gridsome/remark-prismjs: pour effectuer une coloration syntaxique.

• remark-inline-links: pour pouvoir gérer les liens inclus (qui sont ensuite reportés en bas du fichier)

  [foo], [foo][], [bar][foo].
  
  ![foo], ![foo][], ![bar][foo].
  
  [foo]: http://example.com "Example Domain"

• remark-attr: pour pouvoir ajouter des attributs à une image ou à un objet.

  ![alt](img){attrs} / ![alt](img){ height=50 }

• remark-toc: pour pouvoir ajouter un sommaire à certain billet.
• remark-footnotes: pour pouvoir ajouter les footnotes.

Création du thème

Le thème Pelican de mon blog est basé sur alexandrevicenzi/Flex. J'ai donc créé un thème gridsome en reprenant le style du thème précédent mais en convertissant les templates en Vue.Js.

J'ai donc créé ce thème que j'ai mis à disposition ici : phoenix741/gridsome-flex-markdown-starter.

Voici la configuration de gridsome que j'ai implémenté pour reconstruire le thème du blog:

  plugins: [
    {
      use: "@gridsome/source-filesystem",
      options: {
        baseDir: "content/posts",
        path: "**/*.md",
        typeName: "Post",
        refs: {
          tags: {
            typeName: "Tag",
            create: true,
          },
          category: {
            typeName: "Category",
            create: true,
          },
        },
      },
    },

Pour commencer, on utilise le module @gridsome/source-filesystem pour lire le contenu du dossier content/posts/**/*.md. On définit au plugin comment on créé les Tag et les Category.

    {
      use: "@microflash/gridsome-plugin-feed",
      options: {
        contentTypes: ["Post"],
        rss: {
          enabled: true,
          output: "/feed.xml",
        },
        atom: {
          enabled: true,
          output: "/feed.atom",
        },
      },
    },

Ensuite on crée un flux RSS et un flux ATOM avec ces posts, afin que les lecteurs qui utilisent encore un lecteur de flux, ou les programmes qui s'abonnent directement à mon site fonctionnent encore.

    {
      use: "@gridsome/source-filesystem",
      options: {
        baseDir: "content/pages",
        path: "*.md",
        typeName: "BlogPage",
      },
    },

On recommence avec les pages du site, que l'on type comme BlogPage. Ces pages ne seront pas accessibles via des catégories ou des pages. Il faudra faire des liens directement vers les pages depuis un menu.

    {
      use: "@gridsome/plugin-sitemap",
      options: {
        config: {
          "/post/*": {
            changefreq: "weekly",
            priority: 0.5,
          },
          "/page/*": {
            changefreq: "monthly",
            priority: 0.7,
          },
        },
      },
    },

Après, on définit un sitemap qui pourra être utilisé par les moteurs de recherches.

  ],
  templates: {
    Post: (obj) => {
      return (
        "/post/" + obj.fileInfo.name.replace(/^\\d{4}-\\d{2}-\\d{2}[_\\-]/, "")
      );
    },
    BlogPage: "/pages/:fileInfo__name",
    Tag: "/tag/:id",
    Category: "/category/:title",
  },

On définit les différentes chemins d'accès pour nos billets, nos pages, nos Tag, et nos Category. Comme je ne souhaite pas changer les adresses de mes billets sur mon site, j'ai défini les adresses sur les mêmes chemins que mon blog sous Pelican.

Comme les noms des fichiers des billets portent la date et le nom du billet, pour retrouver le nom du chemin d'origine, je supprime la date pour la génération du chemin.

  transformers: {
    remark: {
      plugins: [
        ["@gridsome/remark-prismjs", { showLineNumbers: true }],
        "remark-inline-links",
        ["remark-toc", { heading: "sommaire" }],
        "remark-attr",
      ],
      config: {
        footnotes: true,
      },
    },
  },

Enfin, je définis les différents plugins dont j'ai besoin pour que mes différents billets fonctionnent correctement.

  permalinks: {
    trailingSlash: "false",
    slugify: {
      use: "@sindresorhus/slugify",
      options: {
        decamelize: false,
      },
    },
  },
  css: {
    loaderOptions: {
      less: {
        // options here will be passed to less-loader
      },
    },
  },
};

Je termine par modifier la manière dont Gridsome transforme les adresses, toujours pour que les chemins de mon blog ne changent pas.

Développement des pages

Viens ensuite l'écriture des différentes pages, composants et layout pour définir notre thème. Le plus compliqué, c'est que le résumé (excerpt) fourni par Gridsome supprime le rendu HTML et les retours chariots.

Je voulais que sur la page principale de mon application, je puisse générer un résumé de chaque billet avec le texte et le rendu original du billet.

Pour cela malheureusement Gridsome ne fournit pas une manière simple de générer un résumé. Je vais vous présenter mon implémentation afin d'avoir un résumé au format Markdown.

Ma première version a été de créer à partir de contenu HTML le résumé dans un composant vue dédié. Lors de la génération des pages statiques, le résultat était comme attendu. Par contre lors du changement des pages (en mode SPA), le billet intégral du blog est chargé, pour être tronqué dynamiquement. Ce qui est long et pas performant quand cela arrive sur 10 billets à la suite. J'ai donc modifié le système pour générer les pages côté serveur.

Pour cela j'ai donc modifié le fichier gridsome.server.js. Le problème, c'est que Gridsome ne permet pas d'appeler un transformer (remark) directement, et ne permet pas de convertir un text en markdown (autrement qu'en passant par le plugin @gridsome/source-filesystem).

J'ai donc dû implémenter l'appel à remark (et les différents plugins) directement dans la partie serveur manuellement.

Une fois le fichier HTML obtenu, j'appelle une librairie dédiée truncatise afin de réduire le contenu à quelques paragraphes (4).

const truncatise = require("truncatise");

const remark = require("remark");
const html = require("remark-html");

const remarkPrism = require("@gridsome/remark-prismjs");
const remarkInlineLinks = require("remark-inline-links");
const remarkToc = require("remark-toc");
const remarkAttr = require("remark-attr");
const remarkFN = require("remark-footnotes");

module.exports = function(api) {
  api.loadSource(({ addSchemaResolvers }) => {
    addSchemaResolvers({
      Post: {
        excerpt: {
          type: "String",
          async resolve(obj) {
            return new Promise((resolve, reject) => {
              remark()
                // Appel des différents plugins utilisé coté config.
                .use(remarkPrism)
                .use(remarkInlineLinks)
                .use(remarkToc, { heading: "sommaire" })
                .use(remarkAttr)
                .use(remarkFN)
                // Génération HTML
                .use(html)
                .process(obj.content, function(err, file) {
                  if (err) {
                    return reject(err);
                  }

                  // On tronque en ne gardant que les 4 premiers paragraphes
                  resolve(
                    truncatise(String(file), {
                      TruncateLength: 4,
                      TruncateBy: "paragraphs",
                      Strict: false,
                      StripHTML: false,
                      Suffix: " ...",
                    })
                  );
                });
            });
          },
        },
      },
    });
  });
};

C'est ainsi que j'ai converti mon blog vers le framework Gridsome. Je vous passe tous les détails (vu que le thème est disponible sur Github sur phoenix741/gridsome-flex-markdown-starter).

Ajout d'un système de commentaire

Ce qu'il manquait sur mon blog précédent c'était un système de commentaires. J'ai donc ajouté ce système de commentaires à mon blog.

Je ne souhaitais pas ajouter n'importe quel système de commentaires. J'ai donc regardé ce que je pouvais ajouter sur un site statique. On va retrouver les systèmes de commentaires non libres, et faciles à implémenter (et pas forcément très compatible RGPD).

• Disqus
• Facebook comments
• ...

De mon coté je me suis dirigé vers les systèmes de commentaires libres:

• Vssue
• Gitment
• Utterances
• Remark42

Remark42 nécessite l'installation d'un programme sur mon serveur. Je l'ai testé mais j'ai été à quelques problème lors de l'intégration avec Gridsome.

Vssue, Gitment et Utterances sont intéressants car ils permettent d'ajouter un système de commentaires se basant sur le système de ticketing de Github. Github n'est en lui même pas OpenSource mais les frameworks ci-dessus le sont.

Je considère que la plupart des personnes lisant mon blog ont un compte Github. Mais n'hésitez pas à commenter si ce n'est pas le cas ;).

Vssue était mon système préféré, beau, simple compatible avec Gitea (que j'utilise pour mes sources), Gitlab, et avec Github également. Mais dû aux limitations de Github et Gitea, il m'était nécessaire de fournir mon ClientSecret OAuth2.

Je n'ai pas apprécié cette idée mais j'ai tout de même voulu tester. Là je me suis rendu compte qu'il y avait des problèmes CORS. Le composant passe par CORS Anywhere mais ce dernier ne peut être utilisé que pour le développement. Ce qui signifie que je dois installer un proxy équivalent sur mon serveur. J'ai donc regardé pour autre chose.

J'ai alors testé Utterances. Le problème est que cette librairie n'est pas compatible avec les applications de type SPA. On peut voir d'ailleurs quelques commentaires sur le ticket Github #231 de personnes ayant tenté de faire une version du client pour Vue.Js.

Je me suis donc inspiré d'un composant Vue.JS écrit par quelqu'un d'autre (dans le 1er commentaire) pour inclure ce système sur mon site. Ce composant a dû être légèrement adapté pour fonctionner (je vous invite à regarder GithubComponent.vue).

Comme le plugin utilise directement l'objet window, il ne peut fonctionner avec le mode SSR (Server Side Rendering) de Vue.Js. J'ai dû donc désactiver le mode commentaires pour le côté SSR (la génération). Ce n'est pas déconnant car de toutes façon les commentaires sont gérés sur Github.

Voici comment on fait avec Gridsome. On commence par encadrer le bloc qui ne doit pas faire partie de la génération côté serveur (et qui est donc Client Only). Ce bloc contient notre composant GithubComponent.

<article>
  ...
  <ClientOnly>
    <div class="commentswrap">
      <div id="comments">
        <GithubComponent
          :title="$page.post.title"
          :repo="$page.metadata.utterances.repo"
          :pathname="this.$route.path"
          :url="url"
          :issueTerm="$page.metadata.utterances.issueTerm"
          :label="$page.metadata.utterances.label"
        >GithubComponent>
      div>
    div>
  ClientOnly>
article>

Enfin on charge le composant dynamiquement dans la partie Javascript.

export default {
  components: {
    PostHeaderTitle,
    GithubComponent: () =>
      import("../components/GithubComponent")
        .then((m) => m.default)
        .catch(),
  },
  ...
}

Ces deux opérations permettent d'exclure cette partie lors de la génération des pages statique, mais de l'ajouter dynamiquement après le chargement de la page coté client.

Conclusion

Voici donc comment j'ai mis en place la version Vue.JS de mon blog. N'hésitez pas à m'envoyer un mail ou lâcher un commentaire.

Vous pouvez retrouver le kit de démarrage que j'ai fait pour mon blog sur github: phoenix741/gridsome-flex-markdown-starter. Vous pouvez également consulter l'intégration d'utterances sur un site en vue ici: phoenix741/gridsome-flex-markdown-starter:GithubComponent.vue.

Original post of Ulrich Van Den Hekke.Votez pour ce billet sur Planet Libre.

Pour la 8ème semaine de l'année 2021, voici 12 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

• Une infra en Data Center ?
• Le logiciel libre dans l'environnement de la Gendarmerie nationale
• Bienvenue sur Libreon !
• Le télétravail, c'est pas que pour la pandémie !
• Êtes-vous sûrs de vos bonnes pratiques ?
• Scraper des paroles de chansons avec requests et Beautiful Soup
• Installer son serveur XMPP avec Prosody
• [OpenBSD :: Virtualisation] Hôte et invité(s) sont sur le même bateau
• FreeBSD + Ntopng : Transformez votre Raspberry Pi en IDS
• Le Wiki d'Herminien, l'informatique expliqué à tes potes
• Consommer "Local-First" en informatique
• Mon point de vue détaillé sur l’auto-hébergement

Pour ne plus rater aucun article de la communauté francophone, voici :

• Le flux RSS du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker :)

Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Tout d'abord il me faut indiquer quels usages je fais de mon téléphone.

J'utilise surtout les fonctions SMS et MMS, appareil photo et voix – dans cet ordre, de sorte que mes critères sont en général la qualité de l'appareil photo, l'autonomie, une taille raisonnable (un point qui devient difficile à satisfaire), et bien sûr la prise en charge d'un système d'exploitation libre (comme LineageOS par exemple). Mon forfait est à l'avenant puisque je recours au forfait 2€ de Free permettant 2 heures de communication, SMS/MMS illimités et un opulent forfait Internet 50 Mo. Mon usage, généralement dépourvu d'internet comme vous l'aurez compris, me permet plusieurs jours d'autonomie (généralement une semaine – contre deux pour le NOKIA 6020 qui précédait mon basculement, il y a cinq ans, dans le monde des smartphones).

Ce Samsung S5 est mon quatrième smartphone, un peu malgré moi d'ailleurs (j'y reviendrai).

Après un ZTE OpenC sous Firefox OS (acquis neuf en janvier 2016, 30€), les suivants ont tous roulé LineageOS : Sony Xperia Z5 Compact (acquis neuf en octobre 2018, 140€), Samsung Galaxy A3 2017 (acquis neuf en juillet 2019, 170€) et le petit dernier (acquis neuf en décembre 2020, 89€) : un Samsung Galaxy S5 (oui, oui, un modèle lancé en 2014).
C'est une chute de trop (malgré leur étui de protection) qui m'a poussé à remplacer successivement les Xperia Z5 Compact (plus de mise au point de l'appareil photo) et Galaxy A3 2017 (hémorragie de cristaux liquides inondant l'écran). Pour des objets du quotidien, ces appareils sont très peu solides.

Je dirais simplement que je suis très content de ce modèle à l'appareil photo de qualité, à la batterie amovible, extensible par carte SD jusqu'à 128 Go, qui reçoit des mises-à-jour hebdomadaires et qui m'a été conseillé sur LinuxFr comme sur le forum de HFR (merci à vous !).

Pour installer LineageOS, les seuls conseils que je donnerais sont :

• Pour ce qui est du logiciel Heimdall, j'ai eu recours au paquet heimdall-flash de ma Debian qui marche sans souci ;
• Le flashage fonctionne sans carte SIM (le temps de récupérer une micro SIM) ;
• Le câble Samsung fonctionne bien pour charger l'appareil mais visiblement pas pour transférer des données : j'ai dû utiliser un autre câble, celui de ma lampe de vélo ;-)

Si je dois citer trois petits bémols :

• En mode téléphone l'écran s'éteint, notamment quand j'appelle mon répondeur : pas pratique pour appuyer sur le clavier pour effectuer les commandes. Ou quand je décroche. Si j'approche le tél de mon oreille et l'éloigne, l'écran va se rallumer puis se réteindre. Faudra que je note précisément les cas d'usage car ce n'est pas tout le temps. Quelqu'un a t-il ce problème ?
• Si l'on veut sauvegarder directement les photos sur la carte SD, les logiciels ne le gèrent pas très bien. Finalement j'ai décidé de les enregistrer sur le téléphone lui-même, quitte à les transférer d'un bloc quand je manquerai de place (bug connu, voir la page dédiée à cette ROM).
• Le format du téléphone est un peu grand par rapport à ce que j'avais avant, mais bon (surtout avec l'étui géant façon playschool que je lui ai adjoint).

Au final j'apprécie la qualité des photos en extérieur, l'endurance très correcte de la batterie, la réactivité du système et de Fennec F-Droid (alias Firefox Mobile), les mises à jour… J'espère qu'il durera !

Original post of antistress.Votez pour ce billet sur Planet Libre.