j’ai heureusement fait un git add ; git commit -a très récemment, et malheureusement un rm dans le même mauvais répertoire (c’est rm qui est mauvais, pas le répertoire, … bon)
Je cherche la commande de git qui rétablirait tous ces fichiers (5 ans de comptes-rendus hebdomadaires d’utilisation… hebdomadaire!)
J’ai essayé: git checkout de différentes façons, sans trouver la bonne formule, je crains de faire une manœuvre irréversible, la loi de Murphy étant grandement favorisée par mon ignorance!
Ca serait bien d’éviter de répondre… plutôt que d’étaler ainsi ton ignorance, même du sujet !
Si l’idée peut sembler intéressante, il faut l’utiliser depuis un autre système, sur le disque en question - donc non « fonctionnel » - et sauvegarder ce qui pourrait l’être vers une autre partition, hors ce disque dur !
Et aucune sauvegarde régulière de ce genre de données qui semblent si importantes !?
Je dispose bien entendu d’une sauvegarde sur disque externe, mais que je ne le transporte pas avec moi.
En urgence, j’espérais donc pouvoir utiliser git checkout, que j’utilise sur ce répertoire comme sauvegarde d’urgence.
Sauf que je sais faire (je crois!) un git commit -a en guise de sauvegarde, mais apparemment pas vraiment la commande git pour restaurer le dernier état «commité».
Chez moi, j’ai heureusement pu tout restaurer avec rsync.
Mais ma question demeure…
La commande git utilisée (non dans un script, mais dans un alias) est la suivante:
Je ne suis pas informaticien, et à part quelques petits scripts, je ne programme pas.
En revanche j’écris beaucoup, et j’utilise beaucoup LaTeX.
J’utilise git de plus en plus pour avoir un historique de versions, surtout, initialement, avec LaTeX qu’il est très facile de casser dés que je veux modifier quelque-chose d’autre que du texte, et même pour retrouver d’anciennes versions de texte souvent ou tardivement remanié.
Pour ma prise de notes hebdomadaire, j’ai donc un alias qui m’ouvre le bon répertoire, charge vim avec l’entête de la réunion et la date après avoir déchiffré les fichiers de notes précédents, utilisés pour consultation en cours de réunion.
Un script de fermeture fait l’inverse et en plus met à jour les fichiers par un «git commit».
Je n’utilise pas de réseau (à part internet, de chez moi, évidemment), mes seuls dépôts git sont donc locaux, et même spécifiques à différents répertoires.
Les commandes git utilisent en priorité le dépôt git le plus proche dans l’arborescence.
Autrement dit, elles ne se réfèrent au dépôt de la racine utilisateur que s’il n’y en a pas d’autre dans son «path» (son chemin ou son «dirname» si vous préférez).
En résumé,
pour ces 2 répertoires de prise de notes, j’ai 2 scripts, ouverture et fermeture de séance, pour chacun des 2 répertoires (et 2 dépôts git), et pas de réseau.
Je fais heureusement de «vraies» sauvegardes sur un disque dur externe, avec un script basé sur rsync, mais «git commit» est immédiat et systématique.
git log fournit un numéro d’identification du commit
*git checkout <le n°> place sur une sorte de branche provisoire (You are in ‹ detached HEAD › state…) l’état de ce commit (pour moi actuellement, les fichiers *txt et *pdf, les pdf sont des courriels reçus, pas de LaTeX dans ce travail)
Mais je n’ai certainement pas compris car cette commande n’a eu aucun effet.
(Mes aliases sont incohérents, car git sauve mes notes avant chiffrage, ce qui n’assure évidemment pas vraiment la confidentialité recherchée! cette discussion vient de m’en faire prendre conscience!)
PS
git est aussi très utile pour préserver l’historique de mon fichier d’aliases, «~.bash_aliases», et les autres fichiers «~/.bash».
te permet de basculer d’une branche à l’autre, voire de restaurer des fichiers d’une branche de travail.
Là, ton problème n’est pas un problème dû à un mauvaise usage de git.
Ainsi, si c’était le cas, tu aurais peut-être pu faire : git checkout -- <filename>
Je ne vois pas comment git pourrait rétablir la situation qu’il ne connaît pas.
Hormis, de faire un clone depuis ton git de sauvegarde, ou un git pull… pour récupérer les fichiers dans un état précédent.
Tu n’as vraiment besoin de rien d’autres pour essayer d’appréhender les profondeurs et délicatesses de git, si ce n’est des tutos bien fichus - et il en existe quelques uns.
Voila l’erreur:
D’une part j’omettais le «- -», accusé sans doute à tord de mon échec
D’autre part je mettais «*» comme noms de fichiers.
Fichier_* n’est pas un nom valide pour une liste de fichiers, donc pas non plus «*», sauf s’il est mis entre guillemets: «"*"» fonctionne.
La formule (que j’ai utilisé dans mes tests) pour récupérer tous les fichiers effacés depuis le dernier commit 0123abc est donc, simplement:
git checkout 0123abc -- "*"
sans oublier les «- -» ni les guillemets autour de «*»: "*".
Merci pour ces liens (je me réfère à ProGit 2e édition en français, je crois que c’est le même que git-book).
Au temps pour moi, j’ai cru bien faire. C’est vrai que j’ignore ce qu’est Git, c’était certainement le mot clé dans ton titre. Toutes mes excuses. Pdt c’est Président directeur technique ?
Spécialement pour PengouinPdt , mais pour tout utilsateur de git et du shell bash.
Pour me simplifier le travail, bien que j’utilise rarement la facilité des branches sous GIT, mon prompt affiche l’existence d’un dépôt git dans le répertoire ou un répertoire parent en précisant la branche active.
Voici le script chargé dans .bashrc:PS1rc.txt (1,8 Ko)
(son extension est .sh ou rien du tout, et non .txt, nécessité par le filtre du forum)
J’utilise Bash comme shell mais j’ai ajouté un très forte valeur ajouté avec Powerline et les greffons sympa de Vim pour la gestion Git, cela me permet de jongler et visuellement savoir où j’en suis.
