Tu utilises bien les techniques que tu veux. Mais quand on donne un conseil technique il me semble qu'on a une certaine responsabilité de prévenir les destinataires des risques potentiels.

En l'occurence un git reset HEAD^ c'est pas une commande triviale à utiliser et je trouve préférable de donner les pistes permettant de corriger une erreur plutôt que simplement poser ça là en se contentant d'un « C'est trop cool [par contre démerdez vous si vous perdez des données à cause de gunwip] »

Donc j'explique pour les lecteur⋅ices qui ne savent pas : git log peut aussi servir à voir l'historique sur un dépot distant, et git reflog sert à retrouver l'historique des commits sur lesquel on est passé.

Pour la différence entre git add . et git commit -a, je trouve peu pertinent d'ajouter au dépôt des fichiers non suivis si on en a pas encore l'usage.

Ça vaut pour les .fuse_hidden qui surviennent de temps en temps dans les montages sshfs, pour les fichiers temporaires d'une librairie qu'on vient de tester et qu'on a pas encore pris le temps de mettre dans le .gitignore, pour les .Trash d'un poste qui n'a pas encore de gitignore global, voire pire ce fichier de conf avec le mot de passe de la base de donnée qui lui non plus reflete un travail en cours et qui n'est pas encore dans le gitignore, etc…

C'est ton choix, moi je préfère prévenir qu'il y a un risque que j'estime non négligeable de perte de donnée, ainsi que de pourrissement de dépôt par des données inutiles ou des fuites de mot de passe.

Pour finir ta remarque sur le piédestal est déplacée, je ne pense pas t'avoir manqué de respect personnel en critiquant ta solution technique. Au risque de me faire traiter encore une fois d'oppresseur intolérant, je te prierai de ne pas verser dans l'attaque perso sans provocation. Peut-être après on fera « la paix. »
(Permalink)