Discussion :

[Gluups]

Bonjour tout le monde,

Pendant un plantage, j'ai réussi à récupérer des choses du disque. Là-dedans il y avait le profil de navigateur, chouette je peux faire autre chose que changer des mots de passe.

J'ai écopé comme j'ai pu avec une clef Macrium Reflect, mais je ne pouvais pas sauvegarder tout le disque puisqu'il ne démarrait pas, alors j'ai copié des répertoires depuis l'explorateur, mais la version gratuite s'arrête en cours de route. Quelquefois elle dit qu'elle manque de mémoire sur une machine qui a 32 Go, quelquefois elle ne dit rien.

Ça fait que la source de mon programme a quelques mois, en revanche de pendant le plantage j'ai le dépôt "distant" de git. Est-ce que ça me permet de récupérer les développements effectuées dans l'intervalle ?

Si j'essaie de le restaurer, pendant un dixième de seconde j'ai un message qui me dit que le dépôt n'a pas encore été utilisé, et je n'ai pas pu lire la suite parce que la fenêtre propriétés / explorateur de solutions est venue s'afficher par dessus, et je n'ai plus retrouvé le message, en tout cas pas dans les notifications, ni sous les fenêtres qui se sont affichées par dessus.
Est-ce qu'il y a moyen de savoir ce que ça dit ?

[Obsidian]

Bonjour,

J'ai écopé comme j'ai pu avec une clef Macrium Reflect, mais je ne pouvais pas sauvegarder tout le disque puisqu'il ne démarrait pas, alors j'ai copié des répertoires depuis l'explorateur, mais la version gratuite s'arrête en cours de route. Quelquefois elle dit qu'elle manque de mémoire sur une machine qui a 32 Go, quelquefois elle ne dit rien.

J'imagine qu'elle essaie de restaurer ce qu'elle peut vers un disque de destination. Vérifie s'il y a suffisamment de place sur le disque en question pour recevoir la sauvegarde.

Ça fait que la source de mon programme a quelques mois, en revanche de pendant le plantage j'ai le dépôt "distant" de git. Est-ce que ça me permet de récupérer les développements effectuées dans l'intervalle ?

Si c'est vraiment le dépôt « distant », oui, à condition que tu aies régulièrement poussé tes modifications vers ce dépôt distant.

Si j'essaie de le restaurer, pendant un dixième de seconde j'ai un message qui me dit que le dépôt n'a pas encore été utilisé, et je n'ai pas pu lire la suite parce que la fenêtre propriétés / explorateur de solutions est venue s'afficher par dessus, et je n'ai plus retrouvé le message, en tout cas pas dans les notifications, ni sous les fenêtres qui se sont affichées par dessus.

S'il te dit qu'il « n'a pas encore été initialisé », c'est mauvais signe car cela voudrait dire que le répertoire concerné a été ouvert, mais que l'on n'a encore rien déposé dedans, ni même lancé git init pour l'initialiser au départ (c'est-à-dire : en faire précisément un dépôt Git) et qu'il est donc vide. Cela dit, on ne sait pas si c'est exactement ce qui y est écrit.

Est-ce qu'il y a moyen de savoir ce que ça dit ?

Oui, mais il vaut mieux utiliser directement la ligne de commande si tu le peux. Les commandes git status, git branch et git log directement depuis l'intérieur d'un de tes dépôts devraient te renseigner.

[Gluups]

Bonjour,



J'imagine qu'elle essaie de restaurer ce qu'elle peut vers un disque de destination. Vérifie s'il y a suffisamment de place sur le disque en question pour recevoir la sauvegarde.

Je veux bien que Macrium Reflect n'a pas toujours des messages complètement clairs, mais quand il n'y a plus de place sur le disque de destination, il dit qu'il n'y a plus de place sur le disque de destination.

Là, il disait qu'il n'y avait pas assez de mémoire, et acceptait de réaliser la suite de la sauvegarde par plus petits bouts. Il faut dire que les morceaux les plus gros et les moins utiles sont au début de l'ordre alphabétique, pas de bol.

Alors pas de place à destination ça va tenir dans une autre discussion. En gros on essayait de sauvegarder tout le disque y compris les espaces vides, alors ça prenait 2 To et non pas les 329 Go annoncés.

Les 329 Go auraient tenu plusieurs fois.

Je faisais un copier/coller depuis l'explorateur, là il se peut qu'ils ne soient pas trop embêtés avec la gestion de la mémoire.

Par ailleurs Macrium Reflect propose une commande de sauvegarde des fichiers et répertoires, là je suppose qu'elle ne se plante pas en route, mais c'est payant.

Est-ce que ça me permet de récupérer les développements effectuées dans l'intervalle ?

Si c'est vraiment le dépôt « distant », oui,

Bonne nouvelle. Implicitement, la question était de savoir comment.

Mais je crains de comprendre d'après ce que tu dis plus loin : il n'y a rien de spécial à faire, mais si l'historique ne fait pas apparaître les dates qui m'intéressent, c'est que la "sauvegarde" du dépôt s'est mal passée, et qu'en définitive il n'y a rien à en tirer.

Encore que l'historique que j'ai vu était celui de la comparaison du code actif (celui d'il y a deux mois) avec le dépôt local (qui date aussi d'il y a deux mois).

Quant à l'historique du dépôt distant, je ne suis pas sûr de moi quant à comment l'obtenir.

à condition que tu aies régulièrement poussé tes modifications vers ce dépôt distant.

S'il te dit qu'il « n'a pas encore été initialisé », c'est mauvais signe car cela voudrait dire que le répertoire concerné a été ouvert, mais que l'on n'a encore rien déposé dedans, ni même lancé git init pour l'initialiser au départ (c'est-à-dire : en faire précisément un dépôt Git) et qu'il est donc vide. Cela dit, on ne sait pas si c'est exactement ce qui y est écrit.

Comme tu dis.
Alors pas initialisé, ça aurait dû, d'ailleurs je me rappelle bien que j'avais pris de bonnes habitudes, et il pouvait y avoir eu deux lignes de changées et pas poussées, et encore pas sûr, mais j'ai bien veillé à toujours avoir 0 en partant, dans la barre d'état.

Bon je vais essayer en fermant les fenêtres qui cachent le message, ça donnera plus d'informations.

Pour l'historique du dépôt distant, on sait faire ?

Est-ce qu'il y a moyen de savoir ce que ça dit ?

Oui

Là aussi, bonne nouvelle, ça aurait été intéressant de savoir comment.

Ah, ça me vient. Un moyen détourné : je ferme les fenêtres de propriétés et explorateur de solutions, et je ferme et rouvre Visual Studio, comme ça il n'y aura rien pour cacher le message ?

mais il vaut mieux utiliser directement la ligne de commande si tu le peux. Les commandes git status, git branch et git log directement depuis l'intérieur d'un de tes dépôts devraient te renseigner.

C'est-à-dire que si je fais ça, logiquement ça va le modifier, le dépôt, ne serait-ce qu'au niveau du statut.
C'est pour ça que je préfère d'abord lui demander ce qu'il a dans les tripes, et ensuite seulement modifier.

Quoique Git Branch et Git Status, oui, j'imagine que ça doit être un "test non destructif".
Mais ce message m'a tellement intrigué que je n'osais rien toucher avant qu'il soit répété.

*

Bon, alors il y avait deux questions.

Pour savoir ce que disait ce message qui apparaissait dans Visual Studio, je vais essayer après avoir fermé Visual Studio avec les fenêtres Propriétés et Explorateur de solutions fermées.

Pour vérifier ce qu'il y a dans le dépôt distant, la bonne question était, quand il n'y a pas de question quant à si le dépôt est valide, comment on fait pour faire apparaître l'historique sur le dépôt distant ?

[Obsidian]

C'est-à-dire que si je fais ça, logiquement ça va le modifier, le dépôt, ne serait-ce qu'au niveau du statut.
C'est pour ça que je préfère d'abord lui demander ce qu'il a dans les tripes, et ensuite seulement modifier.

Normalement non (pour ces commandes en particulier) et en fait, ça doit même fonctionner sur un volume en lecture seule. Si tu crains d'altérer tes sauvegardes par accident, ça peut donc être une bonne idée d'utiliser une copie du répertoire du dépôt concerné pour l'utiliser de la sorte, soit avec un utilisateur aux droits limités, soit en montant un volume en read-only, soit en utilisant carrément un support physique que l'on puisse verrouiller, mais tu as déjà certainement l'habitude de tout cela depuis longtemps.

Il faudrait juste que l'on précise la nature de ton « dépôt distant » car cela fait très longtemps que je n'ai plus utilisé Visual Studio en particulier. C'est-à-dire si tu as réellement sauvegardé le dépôt distant (ou si tu y as toujours accès) ou si c'est seulement l'état des branches « origin/xxx » qu'il te présente de cette façon.

Vérifie qu'il existe un répertoire caché .git en dessous de l'emplacement concerné. Si oui, depuis la racine du dépôt, tu devrais pouvoir faire sans risque git branch pour connaître la liste des branches (au moins locales) déjà déclarées et, de là, git log <nom de branche> pour voir si tu peux la parcourir.

Bonne nouvelle. Implicitement, la question était de savoir comment.

Si ton dépôt distant (sur un serveur quelconque, en principe) est toujours disponible, le mieux consiste à archiver tes sauvegardes puis à « cloner » le dépôt du serveur distant en tant que nouveau projet en local. Normalement, tu devrais tout récupérer jusqu'au dernier commit en date. Si ce n'est pas possible mais que ta sauvegarde est exploitable, tu peux également la « cloner » comme s'il s'agissait d'un dépôt distant, mais il faut ensuite reconfigurer tes branches pour qu'elles pointent à nouveau le serveur.

À défaut, il est possible de récupérer le tout depuis le répertoire car Git est entièrement file-based. Si c'est dans la sauvegarde, ça peut se récupérer mais il se peut que ça demande de mettre un peu les doigts dans le cambouis. Mais pour cela, il faudrait être sûr de ce que l'on y trouve.

[Obsidian]

UPDATE : tu as édité ton message entretemps, je reprends donc tes derniers ajouts :

Quoique Git Branch et Git Satus, oui, j'imagine que ça doit être un "test non destructif".
Mais ce message m'a tellement intrigué que je n'osais rien toucher avant qu'il soit répété.

C'est une sage précaution mais, en effet, git log est censé être non-intrusif lui-aussi.

Pour vérifier ce qu'il y a dans le dépôt distant, la bonne question était, quand il n'y a pas de question quant à si le dépôt est valide, comment on fait pour faire apparaître l'historique sur le dépôt distant ?

Quand le dépôt est valide, il faut d'abord synchroniser le serveur distant avec le local avec git fetch --all ou git remote update (ce qui est intrusif pour le coup, mais il ne s'agit pas encore, à ce stade, d'une fusion avec ta branche locale. Uniquement un rapatriement des données extérieures) puis on consulte l'historique des branches marquées « remote/xxxxx ». Si tu veux vérifier l'avancement d'une branche par rapport à une autre, en général on écrit quelque chose comme git log master..origin/master.

Si le dépôt n'est pas encore valide de ton côté, soit on le clone au préalable, soit on consulte l'interface du serveur si elle en dispose (par exemple un Gitlab ou assimilé), soit encore on lance les commandes directement sur le répertoire distant si tu peux le voir, même en lecture seule. Si le serveur ne propose que SSH, on peut toujours monter le volume à travers SSHFS.

La raison pour laquelle il n'y a pas de commande directe style « git logremote » ou assimilé est qu'il n'y a pas a priori de logiciel serveur Git du tout (même s'il est possible d'en lancer un quand même) – on s'appuie directement sur le système de fichiers déjà en place – et parce que le parcours et l'envoi des données de l'historique constitue 99% du travail à faire. Donc autant cloner ou synchroniser normalement le dépôt et l'exploiter de façon ordinaire derrière.

[Gluups]

OK merci.
Aujourd'hui j'arrive à diminuer mon niveau de stress, et après je vais me remettre là-dessus, je crois que maintenant j'ai de bonnes ficelles.
La nuit dernière j'ai sauvegardé l'image du disque, ce qui fait que si jamais un CHKDSK le plante, je pourrai le restaurer.
On n'est jamais trop prudent avec ça.

Personne n'a jamais émis d'hypothèse sur pourquoi un point de restauration a été incapable de faire démarrer la machine.

[Gluups]

Ah, j'ai jeté un coup d'œil, mais j'avoue que je ne m'attendais plus à ce que j'ai vu.

La machine ayant été réinstallée depuis la création du dépôt, entre temps l'identifiant du propriétaire a changé, ce qui fait que je ne peux pas l'ouvrir.

Ce n'est pas qu'il n'y a rien dedans, c'est que je n'ai pas les droits.

Je me rappelle avoir posé la question.

Ce serait pratique que j'aboutisse mieux cette fois-ci.

Ah oui alors j'ai redéfini le dépôt "distant" il y a quelques semaines, mais comme ensuite j'ai réinstallé une image d'Octobre, eh bien ce n'est plus le même propriétaire. Ma machine ayant été instable ces dernières années c'est sûr qu'il y a eu des réinstallations, mais je dois avouer que j'aurais été incapable de donner les dates.

Alors si je comprends bien, même si j'avais réussi à restaurer le projet original d'avant que je restaure Ocbobre, je n'aurais pas les droits pour y accéder ?

La conclusion où j'en étais arrivé l'autre fois c'est que j'ai transféré la propriété des fichiers au nouveau profil sous Windows, mais que pour Git, ce n'était quand même pas le même propriétaire.
Est-ce que Git garde une trace de son propriétaire ?

N.B. Ça tombe bien que ce soit dans le même forum, comme ça en parcourant son index c'est vite trouvé.

Faire une recherche dans mon historique de navigation, dans le profil sur developpez.net, je ne sais pas si c'est prévu mais apparemment je n'ai pas su où il fallait cocher.

[Gluups]

J'ai remarqué quelque chose en installant Github-Desktop : ils demandent une connexion à Github, histoire de vérifier l'identifiant et le mot de passe, de façon à être sûr de pouvoir se connecter.

Ce n'est pas le cas de Git, à utiliser en ligne de commande.

Il se trouve que ces informations sont stables. Mais je ne sais pas si pour aujourd'hui ça m'avance beaucoup.

En l'absence de réponse à ce problème de changement de propriétaire, nous touchons apparemment une limite de l'utilisation d'un dépôt "distant" sur la même machine.

(Le message précédent aurait dû se terminer par cliquer plutôt que cocher, mais je crains que ça aurait pu être compliqué à suivre si je continuais à faire des modifications.)

[Obsidian]

Bonsoir,

Normalement, le propriétaire des fichiers du dépôt distant est indépendant de celui qui les possède dans le dépôt local. Et heureusement parce qu'il serait difficile d'accepter des contributions extérieures impliquant plus que quelques personnes dans cette situation. Il serait également compliqué de le mettre à la disposition du public (même en read-only) puisque chaque utilisateur devrait déjà appartenir à un même référentiel. Si le serveur distant est géré par un Gitlab sous un unixoïde, par exemple, tous les fichiers de tous les dépôts appartiennent à gitlab:gitlab sur le serveur.

Cela dit, tu me fais douter car les modes d'accès, eux, sont préservés et suivis d'un commit à l'autre. Mais en principe, si ce sont seulement les identifiants du propriétaire qui ont changé, alors tu dois pouvoir réattribuer les fichiers d'un dépôt au niveau propriétaire et les exploiter à nouveau normalement.

La conclusion où j'en étais arrivé l'autre fois c'est que j'ai transféré la propriété des fichiers au nouveau profil sous Windows, mais que pour Git, ce n'était quand même pas le même propriétaire.
Est-ce que Git garde une trace de son propriétaire ?

Pas au niveau des fichiers.

En revanche, les auteurs des modifications apportées à un fichier sont bien sûr conservées dans le commit concerné, mais c'est indépendant du filesystem.

En l'absence de réponse à ce problème de changement de propriétaire, nous touchons apparemment une limite de l'utilisation d'un dépôt "distant" sur la même machine.

Effectivement, l'une des forces de Git est de ne pas avoir forcément besoin d'un serveur explicite et de pouvoir exploiter directement un dépôt distant dans un système de fichiers s'il est visible, ce qui permet de les héberger virtuellement n'importe où mais si on exploite directement le dépôt distant avec son propre compte, même en travaillant sur un copie locale et en poussant en local vers le dépôt de référence, comme c'est directement le processus lancé par l'utilisateur qui va effectuer toutes les opérations, alors on finit par se retrouver avec un dépôt central qui contient des fichiers appartenant à tous les utilisateurs qui y ont participé, ce qui in fine risque de poser des droits d'accès.

Il reste possible de s'en sortir dans tous les cas soit en utilisant les groupes (de sorte que le propriétaire n'importe que peu), soit avec des ACL dédiées, soit en utilisant un système de fichier qui soit configuré pour utiliser un utilisateur générique mais si on le fait un peu plus sérieusement, le mieux reste encore de lancer le daemon sous une identité propre, de le laisser gérer ses propres fichiers et de s'y connecter en git:// ou http://.

[Gluups]

Bon, alors autant pour moi : j'ai vu deux identifiants de propriétaires, j'ai vu refus de connexion, et je me suis arrêté là.

En dessous, ai-je remarqué tout-à-l'heure, était indiquée la commande qu'il fallait taper. Il faut remplacer les apostrophes par des guillemets sinon le système se plaint de ne pas avoir le compte de paramètres, mais à part ça ça marche.

Et cette fois effectivement le Git Status m'indique des formulaires supprimés et des formulaires ajoutés. Il me faudrait passer un peu plus de temps pour voir si j'aboutis avec mon projet, mais ça semble ne plus coincer.

Simplement je peine plus longtemps que je ne m'y attendais.