Reprise du message précédent :

 
S'ils n'ont jamais fait parti d'un commit (normal ou stash ou autre) ils sont perdus pour de bon, ils n'ont jamais fait parti de git en fait.

S’ils ont pas été committés je pense pas, je suis même pas sûr que les ajouter à l’index crée une trace pérenne (mais j’ai très peu d’expérience avec l’index).  
 
Si t’as un FS COW (ZFS, BTRFS) t’as une chance, sinon t’es zob (dans le sens où même si les blocs ont pas été écrasés t’as pas trop de moyen de les retrouver). Regarde ptet dans ton éditeur s’il a pas un système d’historique local? Ou si les fichiers sont pas encore ouverts dedans?

 
Si tu utilises un IDE JetBrains (peut-être même que d'autres IDE le font aussi) tu peux te servir de l'historique sur l'arborescence des fichiers.

 
Du coup je suis en train de lire ça https://stackoverflow.com/questions [...] -git-reset

J'allais dire que c'est plus compliqué que du Qwerty international, mais j'avais pas vu les ligatures, enfin je m'en sers jamais et j'avoue que laisser la correction automatique le faire pour moi me suffit
 
En tout cas passer au qwerty ça prends du temps, j'avais chuté à 50 wpm en y passant il m'a fallu minimum 6 mois pour revenir à 100-110, et j'ai toujours pas rattrapé ma vitesse de frappe sur FR-BE que j'avais depuis plus de 15 ans.
 
Mais on a accès à plus de keycaps etc donc ça vaut le coup

 
Je tente la commande git fsck --full --unreachable --no-reflog, on verra bien.
 
Sinon c'est 1 semaine de boulot en moins... Je sais qu'il faut push de temps en temps mais fait chier quoi

 
æ tu l'as normalement (altgr+Z)  
œ je crois que c'est altgr+K mais uniquement pour la variante linux, windows ne l'a pas hélas (mais vim oui donc ça va )

push ? non, faut juste faire des commits en local, ça suffit pour avoir tout dans le reflog    L'erreur c'est de ne pas commit (même pour des commits 'wip' ou 'temp' ça vaut le coup).

ex: si tu rebases avec autosquash ça suffit ton fichier est quelque part dans le reflog du coup

Je le fais pour les keycaps exclusivement ouais (même si j'ai un set PBT Cherry en ISO-FR). Et pareil je suis passé de 110 à 35 wpm là. J'aime pas les deadkeys et j'ai un clavier 65% donc j'ai pas accès à ` facilement, d'où ce layout.

 
Tu ne commettras pas deux fois cette erreur

Mes confuses, j'ai lu à moitié. Le titre est faux "Adaptateur AC/DC". Tu peux le prendre. La seule chose à vérifier est le diamètre de la sortie jack.

Si t'as un IDE digne de ce nom, tu peux les récupérer avec l'historique local.

Bon je sens que je suis bon pour tout refaire. Heureusement chatGPT lui il garde un historique !

Le reste est sur codepen mais j'ai dû pas mal modifier du code pour l'adapter au projet --'

Merci bien, je ferai attention la prochaine fois --'
Je pensais quand même que git avait une option hyper caché pour récupérer des fichiers delete...

Et je suis sur VSCode

EDIT : C'est bon !, VSCode c'est une tuerie. On recrée son fichier avec le même nom et on va dans TIMELINE sur la colonne de gauche. Y'a toute la liste des actions dessus depuis longtemps. J'ai tout récupéré !

je trouve ça pas mal en fait, ça a l'air plus pratique à utiliser et assez simple à memoriser par rapport au qwerty int
il faudrait que j'essaye

 
Surtout que ALT+GR c'est direct sous le pouce droit donc c'est assez rapide pour faire les combinaisons.

 
Les mecs ont une landing page de layout de clavier OÙ ON NE VOIT PAS DIRECTEMENT LE LAYOUT DE CLAVIER, je devienne fou

 
Les commits en local ça suppose quand même des backups réguliers de la machine dans l'idéal... sinon il faut push oui. L'idéal dans un PR "work in progress" https://github.blog/2019-02-14-intr [...] -requests/  
 

au moins ça pousse à lire et comprendre la logique derrière l'agencement: https://github.com/qwerty-fr/qwerty [...] y-overview
chose que je n'aurais pas rapidement compris en regardant juste le layout

 
Pour le coup, vu que le layout est littéralement le premier élément du readme GitHub, ça ne change pas grand chose.

Mais donc la réponse est oui, `git add` ajoute tous les objets à l’odb.

+1, tu peux tout committer en wip (même si je préfère mettre un minimum d’explications) puis tu commit —amend par dessus ou bien de temps en temps tu rebase -i pour nettoyer.

 
IME la probabilité de merder un truc et de supprimer ou niquer un fichier (parce que t’a parti en vrille sur une modif) est infiniment plus haute que la machine qui prend feu et est perdue corps et bien y compris le disque.
 
Bonus supplémentaire si tu utilises des bare repos dans un coin planqué et que tu fais des worktree dans lesquels tu bosses, comme ça même si tu rm -rf ta copie malencontreusement la vérité est ailleurs.

perso je fais les deux: commits réguliers et push "work in progress" en fin de journée
 
et j'ai aussi du backup, c'est utile si tu oublies de faire un add ou que ton .gitignore est foireux et masque un fichier important

Je suis pas un bon touch typist, mais j'ai toujours du d'avoir taper en QWERTY a cause des jeux vidéos, les premiers jeux online savaient pas lire le layout de l'OS, donc a produisait q systématiquement
Quand j'ai bouge en Suisse, pour éviter le QWERTZ du malin, j'ai appris le QWERTY avec US intl en layout, et c'est top

Git commit souvent, et tu amend / rebase pour nettoyer les commits bruyants

This. J'ai découvert cette façon de faire récemment, c'est pas mal (en regardant FasterThanLime, il commit tout le temps, des qu'une idée est implémentée, même si c'est 3 lignes)

Le seul truc chiant c’est que si t’as beaucoup tendance à fixuper des commits plus anciens, git est pas foutu de te dire quand tu permutes des commits de manière pas compatible, donc tu lances le rebase et il te balance un vomi de conflits #darcscétaitbien.
 
Et splitter autant committer des morceaux de working copy c’est facile, autant splitter un commit existant c’est assez galère. Faudrait que je regarde s’il existe des scripts pour faciliter ça, ou que je m’en monte un.

Il peuvent être dans l’historique local de l’IDE

C'était le cas, c'est bien ça qu'il y ait un historique en plus pour éviter ce genre de mésaventure à nouveau.

Moi je l’utilise plusieurs fois par jour ce truc.

Et laisser les collègues voir comment je code ? Plutôt crever.

Oui après tu as l'historique de l'IDE, le dossier .vimbackup, etc.
 
Le plus extrême que j'ai eu (mais j'étais jeune hein) c'est le code perdu pour de bon et plus rien dans l'IDE, mais les dll et le binaire étaient toujours sur le disque et c'était du .NET Ça se reverse super bien avec ilspy et hop le code (à peu près) récupéré

tu forkes dans ton userspace et met le repo en private  

J'avais plus le CSS en local et mon IDE ne me donnait pas la timeline du fichier.
Heureusement que j'ai toujours mon browser d'ouvert avec mon historique de la veille. J'ai pu aller récupérer tout ça dans le network et c'était bon.
 
On ne soupçonne pas tous les historiques qu'on a jusqu'à qu'on ait absolument besoin

 
C'est toujours bien de marquer des milestone régulièrement, c'est trop con de se dire "merde faudrait que je tente autrement, si seulement je pouvais revenir en arrière ya 30min quand le truc de base marchait".  git rebase rendra tout propre et beau à la fin de toute façon.
 
(Si t'as jamais fermé ton éditeur tu peux y arriver à coup de ctrl-Z mais c'est quand-même bien précaire, encore que les :earlier et :later sont très puissants mébon...)

 
Une fois j'ai crashé un disque, ben entre les pièces jointes d'email, les clef usb, les copies parcellaires de dossiers qui trainent sur le pc du taf/le smartphone/etc j'ai été surpris de pouvoir retrouver une aussi grande partie des données comme quoi le bordel ça aide

Ici tout ce qui se passe dans un dossier de code est sauvé dans le cloud toutes les secondes. On en garde une copie toutes les secondes de la dernière minute, toutes les minutes de la dernière heure, toutes les heures du dernier jour, et tous les jours. C'est compliqué de perdre son travail.

J'ai pas fait le bilan carbone, mais je suis sûr que c'est pas pire que nos tests d'intégration

non mais c'est bon ya des offsets

heuuu c'est pas un peu exagéré ?  

Sinon y’a jujutsu que j’ai vu passer 2-3 fois, qui se targue d’être compatible git et qui commit tout (genre la working copy / index est un commit).

Ils n'ont pas de dossier node_modules

Non mais on sauve les diffs hein. Et on partage node_modules avec tous les utilisateurs d'une bibliothèque externe donnée (seulement pour les apps NodeJS, pas pour les app webs qui n'utilisent pas npm).

c'est un fork d'une grosse boutique pro, j'imagine que le dimanche ils ont ~0 commandes donc ça permet de les charger le lundi matin avec les particuliers
 
c'est pas une question d'économies, c'est histoire d'être sûr que l'alim sera conforme à celle d'origine (des fois que le barrel jack soit à la con, après tu peux toujours couper et réutiliser l'ancien )
le changement de boîtier je peux te le faire si t'es pas trop pressé, ça te coûtera que 2 MR en plus (mais il faut trouver la bonne taille de boîtier et espérer trouver un moyen pour pas que ça se promène trop dedans )
 

"Mixed signals" comme on dit

Ce qui veut dire que... tu les as appelés ?