Commande Git revert

Bonjour à tous,
Je voudrais tester la commande revert de GIT en faisant comme ceçi dans GitBash

Code:

---

1 2 3 4 5 6 7 8

$ mkdir git_revert_test $ cd git_revert_test $ git init . $ touch revert.md $ git add revert.md $ git commit -am"initial commit"

---

J'ai ensuite modifié le fichier revert.md avec notepad++
puis

Code:

---

1 2	$ git commit -am"Initial Content"

---

J'ai ensuite remodifié le fichier revert.md avec notepad++
puis

Code:

---

1 2	$ git commit -am"prepend content to demo file"

---

puis

Code:

---

1 2 3 4 5

$ git log --oneline 4d00263 (HEAD -> master) Prepend content to demo file eef57da Initial Content 43dcbad Initial Commit

---

puis ensuite je fais le revert pour annuler le dernier commit

Code:

---

1 2	$ git revert HEAD

---

et j'ai l'erreur suivante :

error: your local changes would be overwritten by revert.
hint: commit your changes or stash them to proceed.
fatal: revert failed

Si quelqu'un a une idée MERCI

Bonjour,

Effectivement, Git considère qu'il y a des choses qui, malgré tes commandes, sont encore en suspens et n'ont pas été commités. Peut-être as-tu modifié une fois de plus le fichier en question ou peut-être en as-tu ajouté d'autres à côté ?

Quoi qu'il en soit : git status et git diff te diront de quoi il s'agit.

Rappel : tu le sais sans doute, mais git revert est une annulation « à la wikipédia » d'un commit donné, c'est-à-dire qu'il ne va pas supprimer le dernier commit en date mais appliquer le différentiel inverse, ce qui va prendre la forme d'un nouveau commit dans l'historique et dont l'effet est d'annuler tout ce que le commit ciblé a introduit.

Bjr j'ai exécuté git diff voiçi sa réponse :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$ git diff diff --git a/revert.md b/revert.md index 18fa135..5697b3a 100644 --- a/revert.md +++ b/revert.md @@ -1 +1 @@ -revert Iniitial content \ No newline at end of file +revert Prepended line content \ No newline at end of file

---

Apparement il y aurait un problème entre le 2ème commit et le dernier (HEAD) (No newline)

quand je fais git status :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: revert.md Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: revert.md

---

Qu'en penses tu ?Quoi faire ?

Si je reprends tes réponses et que j'y ajoute la couleur, que tu devrais voir dans ton terminal, on obtient en principe :

Code:

---

1 2 3 4 5 6 7 8 9 10

$ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: revert.md Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git restore <file>..." to discard changes in working directory) modified: revert.md

---

et

Code:

---

1 2 3 4 5 6 7 8 9 10

$ git diff diff --git a/revert.md b/revert.md index 18fa135..5697b3a 100644 --- a/revert.md +++ b/revert.md @@ -1 +1 @@ -revert Iniitial content \ No newline at end of file +revert Prepended line content \ No newline at end of file

---

Cela signifie deux choses : tu as d'une part porté des modifications au fichier revert.md et tu as effectué un git add dessus pour les ajouter au prochain commit. Elles sont actuellement dans l'index, et tu dois pouvoir voir de quelles modifications il s'agit à l'aide de « git diff --cached », même si tu as de nouveau modifié le fichier entretemps, d'ailleurs.

Tu as d'autre part porté de nouvelles modifications à ce même fichier, qui elles n'ont pas encore ajoutées avec git add (alors même que les précédentes sont dans l'index mais pas encore commitées). Ce sont celles que tu vois dans le deuxième paragraphe.

Le fait d'avoir des choses en suspens dans l'index (chose que Git voit au fait que le contenu de l'index est différent du contenu du dernier commit en date) suffit à empêcher l'opération car celle-ci modifiera cet index. Mais il est également possible, même avec un index propre, que l'opération git revert cible le fichier également en question en écrasant les lignes que tu as modifiées, ce qui, là aussi, empêcherait l'opération de se faire.

Comme il est indiqué dans le message d'erreur de ton message initial, il faut soit commiter tes changements pour de bon, soit les mettre de côté avec git stash pour y revenir plus tard.

Citation:

---

error: your local changes would be overwritten by revert.
hint: commit your changes or stash them to proceed.
fatal: revert failed

---

ATTENTION : la situation dans laquelle tu trouves est très courante. C'est l'exploitation normale d'un dépôt Git. Par contre, il faut maintenant que l'on sache pourquoi tu veux effectuer git revert. Si c'est juste essayer la commande ou pour annuler légitimement les effets d'un ancien commit, alors règle simplement la situation de ton fichier pour pouvoir continuer.

Si, en revanche, c'est précisément pour abandonner tout ce que tu as en suspens de ce côté et revenir au dernier état propre en date que tu t'es tourné vers git revert, alors ce n'est pas la manière de procéder (contrairement à Mercurial qui propose une commande qui porte le même nom mais ne fait pas du tout la même chose). Dans ce dernier cas, il faudra passer en revue les subtilités de git checkout et git reset. On peut également évoquer git restore mais comme cette dernière commande est encore relativement récente, on ne l'évoquera quand dans un second temps.

Citation:

---

Envoyé par Obsidian

Cela signifie deux choses : tu as d'une part porté des modifications au fichier revert.md et tu as effectué un git add dessus pour les ajouter au prochain commit. Elles sont actuellement dans l'index, et tu dois pouvoir voir de quelles modifications il s'agit à l'aide de « git diff --cached », même si tu as de nouveau modifié le fichier entretemps, d'ailleurs.

---

Bjr et merci pour ton aide,
J'aimerais reprendre pas à pas tes remarques car il y a des choses que je ne comprends pas dans ta première remarque :
en effet tu parles d'index j'ai regardé l'index est "une zone d'assemblage entre votre répertoire de travail et votre dépôt."
Voilà ce que donne git diff --cached

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$ git diff --cached diff --git a/revert.md b/revert.md index 5697b3a..18fa135 100644 --- a/revert.md +++ b/revert.md @@ -1 +1 @@ -revert Prepended line content \ No newline at end of file +revert Iniitial content \ No newline at end of file

---

Mais à quoi correspondent concrètement ces index et comment voir les modifications ?

Citation:

---

Envoyé par xeron33

Voilà ce que donne git diff --cached

[…]

---

Si tu regardes attentivement le différentiel présenté, tu verras qu'il est en fait l'inverse de celui présenté par git diff seul. revert va faire un travail similaire mais ici, c'est simplement un hasard.

On voit en fait que tu as modifié une ligne, que tu as ajouté cette modification avec add pour commit, puis que tu as annulé à la main cette modification en modifiant à nouveau ton fichier pour le faire revenir à l'état antérieur, avant d'avoir commité.

Citation:

---

Mais à quoi correspondent concrètement ces index et comment voir les modifications ?

---

Effectivement, tu arrives au stade où il devient nécessaire de se former proprement à Git et on avait déjà évoqué le sujet dans un autre fil.

Le principe est relativement simple une fois qu'on l'a saisi et respecte globalement ce qui se fait avec les autres VCS, sauf que Git va le faire de manière beaucoup plus intelligente. Le tutoriel que tu évoques et qui fait état d'une « zone d'assemblage entre… » fait référence à la « staging area » qui est le nom que l'on donne souvent à l'index de Git en particulier. En fait, c'est l'approche adoptée qui en fait « de facto » une staging area et c'est présenté comme cela dans la documentation aussi.

« L'index » (parce qu'il n'y en a qu'un par dépôt) est simplement la liste des fichiers qui sont suivis par le dépôt et c'est comme cela que ça fonctionne avec les autres SCM depuis RCS et CVS. On estime (en majeure partie à raison) que le working directory d'un dépôt lui appartient totalement et on pense que lorsque que l'on fait un checkout vers une révision donnée, il l'efface complètement et le ré-remplit avec les fichiers concernés. En réalité, le VCS ne travaille que sur les fichiers qu'il suit officiellement et laisse tous les autres intacts. Il est donc sûr, en principe, de passer d'une version à l'autre tout en maintenant des fichiers non suivis (ou non encore suivis) en parallèle dans le même dépôt.

Sous Git, il s'agit d'un unique fichier qui se trouve sous .git :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ ls .git branches/ COMMIT_EDITMSG config description FETCH_HEAD HEAD hooks/ index ← Lui info/ logs/ modules/ objects/ ORIG_HEAD packed-refs refs/

---

Et précisément, on ajoute à cette liste, au fur et à mesure du développement, les fichiers que l'on souhaite suivre avec la fameuse commande « add » (généralement la même dans la majorité des VCS). De ce point de vue, un nouveau fichier était donc ajouté « une fois pour toutes » avec add au début de son existence, puis n'avait plus besoin de l'être explicitement ensuite. Ça fonctionne d'ailleurs toujours comme cela avec Mercurial et avec d'autres VCS contemporains. Git est une exception notable et il y a de très bonnes raisons à cela, que l'on va développer.

À ce stade, en revanche, la plupart des VCS se contentaient de vérifier à chaque commit si le contenu des fichiers suivis avait changé ou non (parfois même en se contentant d'examiner la date de modification). Cela signifie qu'à chaque commit, l'intégralité des fichiers suivis ayant été modifiés étaient re-enregistrés tels quels sans possibilité de distinction. Un commit était alors un simple « checkpoint », donc un instantané de l'état du dépôt entier à une date donnée, même si on ajoute toujours un message expliquant en principe les modifications apportées et pourquoi on les a faites.

C'est d'ailleurs l'origine du mot « commit », qui est en fait un verbe, et qui ici signifie « s'engager » : on modifie à loisir un dépôt existant, généralement partagé avec d'autres collaborateurs ou contributeurs, et lorsque l'on veut « arrêter » ces modifications et les graver dans le marbre, on signe ses actes. Le dépôt est alors réputé avoir changé de version et l'ensemble de la communauté s'aligne sur ces mises à jour. CVS tenait d'ailleurs un numéro de version auto-incrémenté à chaque commit même s'il ne correspondait pas forcément à celui que l'on donnait au projet hébergé, s'il en avait un.

Avec Git, cela est toujours vrai, et un commit va toujours correspondre à l'état du dépôt entier, en particulier lorsque tu vas rétablir une révision donnée avec git checkout mais il faut se souvenir qu'il a été conçu pour les besoins du développement du noyau Linux. Celui-ci se fait historiquement en envoyant des patches sur la LKML et il est demandé aux développeurs de regrouper les modifications en « unités logiques » (un patch = un objectif précis), ce qui permet aux mainteneurs d'accepter au besoin certains patches et d'en refuser d'autres en l'état.

En outre, le modèle initial présenté ci-dessus rend difficile l'exploitation de branches. Pour reprendre les propos de Linus Torvalds lui-même : « 1) qui dans l'assemblée a déjà utilisé des branches avec CVS ? 2) Qui a aimé ça ? ». Sous CVS, faire une branche revenait surtout à effectuer un fork à partir d'une position donnée et re-fusionner deux branches était un exercice délicat. Sans compter les numéros de version qui commençaient à devenir cryptiques. Outre CVS, c'est BitKeeper qui a été utilisé sérieusement pendant un temps dans le développement du noyau. C'est le changement de politique et une modification de ses conditions d'utilisation qui ont poussé à la rédaction de Git tel qu'on le connaît et qui ont accéléré son développement.

Ceci exposé, pour saisir le fonctionnement de l'index, il faut d'abord parler des objets de Git et de la manière dont il enregistre ses données au premier lieu :

Les objets sous Git

Git enregistre toutes les données du dépôt proprement dit (donc pas ses propres méta-données) sous forme d'objets localisés dans .git/objects. Ces objets prennent chacun la forme d'un fichier ordinaire compressé en .gz et dont le nom correspond à la somme SHA1 de leur contenu avant compression. Ceci en fait d'ailleurs des objets immuables puisque la moindre modification de leur contenu modifierait profondément, par définition, leur signature SHA1.

Il n'existe que quatre types d'objet :

• blob : il s'agit simplement d'une séquence de données de longueur arbitraire. Ce sont ces objets qui reçoivent le contenu proprement dit des fichiers suivis et parfois d'autres sources non structurées ;
• tree : décrit une arborescence. C'est une liste qui, pour chaque entrée, associe un nom de fichier complet (avec ses modes d'accès et son chemin) à la signature SHA1 d'un blob qui en recèle le contenu ;
• commit : forme un commit complet. Il contient le nom et l'adresse e-mail de l'auteur, celle du mainteneur le cas échéant (ou celui qui a effectué le commit), la date et l'heure où cela a eu lieu, plusieurs headers, le message associé, ainsi que la signature d'un objet tree représentant l'état du dépôt au moment du commit et la signature du ou des objets commits « parents », c'est-à-dire le commit auquel succède celui-ci. Un seul parent dans la majorité des cas, mais il peut y en avoir plusieurs en cas de fusion d'une ou plusieurs branches, et zéro dans le cas du commit initial ;
• tag : un objet spécial pour les « tags annotés » dont nous ne parlerons pas ici (les tags ordinaires sont de simples étiquettes).

On remarque que les objets contenant des références à d'autres objets, et ces objets étant tous signés, il n'est pas possible d'en modifier ou remplacer un sans modifier tous ceux qui s'y réfèrent, directement ou indirectement. Pour faire court, ceci forme de fait une blockchain, et ce depuis 2005, c'est-à-dire bien avant que Bitcoin n'en popularise le concept. C'est ce qui permet à Git d'être sûr qu'un contenu portant une même signature sera le même partout et aux développeurs de faire évoluer un même édifice sans avoir besoin d'un autorité de confiance centralisée ;

On constate également qu'un même fichier répliqué dix fois (par exemple) dans le working directory n'aura pas besoin de l'être également dans le dépôt des objets : l'arborescence (l'objet tree) qui liste ces fichiers devra faire référence à dix blobs possédant tous le même contenu et, donc, la même signature. Et en conséquence, ce sera le même objet sur le disque. Donc le fichier en dix exemplaire ne le sera qu'en un seul dans la liste des objets, sans que Git ait besoin de mécanisme dédié pour en faire le contrôle. Cela se produira automatiquement de part même l'architecture du système.

L'index

C'est là que Git, déjà assez intelligent dans le concept, va se révéler particulièrement brillant : lorsque tu appelles git add, Git ne se contente pas d'ajouter le fichier à la liste mais il va également directement y associer son contenu. Il va donc créer un objet blob à la volée qui va recevoir le contenu du fichier tel qu'il est au moment où tu appelles la commande.

En ce sens, l'index est donc un « tree ». Il n'utilise pas exactement le même format que les objets tree pour des raisons d'efficacité, mais c'est lui qui va former l'arborescence associée au prochain commit. Cela signifie que lorsque tu appelles git commit, c'est l'état de l'index qui est enregistré et pas directement celui du working directory.

À chaque fois que tu appelles git add, même avec un fichier qui a déjà été ajouté, l'entrée est mise à jour et le blob associé est remplacé par celui qui correspond au contenu courant du fichier. C'est pour cela que, sous Git, on appelle git add pour soumettre chaque nouvelle modification, là où les autres se contentent d'enregistrer tout ce qui est suivi à chaque nouveau commit, sans distinction.

Ceci te permet déjà de choisir, fichier par fichier, ce que tu souhaites enregistrer dans le prochain commit, les autres fichiers étant considérés comme inchangés (même s'il le sont en pratique dans le working directory). Tu peux ensuite choisir plus finement, au sein d'un même fichier, ce que tu souhaites sélectionner ou non en utilisant git add -p plutôt que git add seul. On y reviendra.

Et c'est également ce même système qui va permettre à Git de savoir ce qui a changé ou non dans ton dépôt sans avoir à en tenir explicitement la trace avec des flags : il lui suffit de comparer entre eux les états du dernier commit en date (ou plus précisément celui qui est déployé par git checkout et référencé par HEAD), de l'index et du working directory :

Cas 1 : le commit en vigueur, l'index et les fichiers du working directory sont tous identiques : cela indique que le contenu du working directory est conforme à celui du commit et que rien n'a été ajouté à l'index. Ton dépôt est « propre » et c'est ce que t'indique git status.

Cas 2 : le commit en vigueur et l'index sont identiques, mais le working directory diffère : cela signifie que des modifications ont été apportées mais qu'elles n'ont pas encore été prises en compte. git status te les affiche en rouge et ce sont elles que tu vois avec git diff. Il faut utiliser git add pour les préparer à l'intégration.

Cas 3 : l'index et le working directory sont identiques, mais le commit en vigueur diffère : cela signifie que tu as fait des modifications au working directory et que tu les as toutes ajoutées à l'index. git status te les affiche en vert et te dit qu'elles seront enregistrées avec le prochain commit. git diff ne t'indique plus rien car il n'y a plus de modification en suspens, mais aussi et surtout parce que pour connaître ces différences, git applique un diff entre le working directory et l'index (pas directement sur le commit en vigueur) ;

Cas 4 : l'index, le working directory et le commit en vigueur sont tous différents : tu as à la fois des modifications qui ont été ajoutés avec git add et des modifications qui ne le sont pas encore. git status te présente à la fois du rouge et du vert. Les modifications en rouge peuvent être aussi bien des modifications déjà présentes mais pas encore ajoutées, soit des modifications qui ont été portées a posteriori après un add, éventuellement sur les mêmes lignes. Cela ne fait aucune différence pour Git, qui les traite de la même façon.

C'est dans ce cas n°4 que tu te trouvais à ton dernier commentaire.

Merci bcp pour toutes ces infos !
J'ai refait mon test, supprimant directement sur mon PC le dossier sur lequel j'avais fais mon depot local(git init) et j'en ai recréé un autre. J'ai eu le même problème avec le révert, en lisant tes infos, je pensais que je pourrai essayer de rajouter(add) mon fichier modifié pour le mettre dans le staging aréa, chose que je n'avais pas faite, puis j'ai refais le git revert et tjrs le même problème, je l'ai refait et tjrs pareil, puis en revoyant un tutoriel, j'ai vu que j'avais oublié de créer un git Ignore, dans lequel j'ai noté les fichiers que je voulais ignorer.
Donc actuellement tjrs pareil avec revert ça marche pas voilà ce que me répond les différentes commandes :

Code:

---

1 2 3 4 5

$ git log --oneline 1902f1f (HEAD -> master) prepend content d8b4545 initial content e901107 initial commit

---

Code:

---

1 2 3 4 5 6 7

$ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: .gitignore modified: revert.md

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

$ git diff --cached diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..5dbcc0b --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +DOC GIT.docx \ No newline at end of file diff --git a/revert.md b/revert.md index 2c00430..d80ce37 100644 --- a/revert.md +++ b/revert.md @@ -1,3 +1,2 @@ -prepend content - +initial content

---

D'après ce que j'ai lu dans tes infos, le git diff me dirais que j'ai modifié le git ignore à la ligne 1 en y ajoutant "DOC GIT.docx" ce qui est vrai,d'autre part il me signale que j'ai enlevé 3 lignes à partir de la ligne 1 et rajouter 2 lignes à partir de la ligne 1 ce qui est surement vrai même si j'ai je pense avoir modifié simplement la ligne 1...

Pourquoi il me demande de "comitter" revert.md (git status) alors que je l'ai déjà fais et que j'ai fais un revert pour annuler mon dernier commit(prepend content) ?
Voilà peux tu me dires aussi si j'ai eu raison de supprimer mon depot local directement dans windows sans passer par une commande git ?

Bonsoir,
Merci beaucoup d'avoir pris soin de poser les couleurs dans tes extraits. :ccool:

TLDR;

Ton dépôt doit être « propre » (tel qu'indiqué par git status) pour pouvoir utiliser git revert. Tu ne peux pas le faire si tu as des choses en suspens dedans.

Réponse détaillée

Citation:

---

Envoyé par xeron33

je pensais que je pourrai essayer de rajouter(add) mon fichier modifié pour le mettre dans le staging aréa, chose que je n'avais pas faite

---

Chaque fois que tu fais git add, tu déposes le contenu actuel du fichier dans la staging area. Plus précisément, tu y remplaces l'ancien contenu par le nouveau, ancien contenu qui, au départ, correspond à celui du commit courant, pointé par HEAD (donc le dernier en date ou celui que tu viens de rappeler avec git checkout). Donc si tu as réussi à faire des commits jusqu'ici, tu as forcément utilisé la staging area (qui, rappelons-le, est le nom informel donné à l'index de Git).

Citation:

---

puis j'ai refais le git revert et tjrs le même problème, je l'ai refait et tjrs pareil, puis en revoyant un tutoriel, j'ai vu que j'avais oublié de créer un git Ignore, dans lequel j'ai noté les fichiers que je voulais ignorer.

---

Je ne sais pas si c'était en rapport avec ce que tu veux faire ou si c'est juste pour détailler les étapes suivies mais .gitignore n'a rien à voir dans ce contexte. C'est un fichier qui sert à faire la liste des fichiers que Git doit ignorer… tant qu'il ne sont pas encore suivis ! Sinon, il n'a aucun effet sur eux. Cela sert principalement à exclure automatiquement les produits de compilation quand on travaille sur un logiciel, par exemple, ou bien les fichiers temporaires de l'éditeur de texte que l'on utilise pour travailler dans le répertoire de travail.

Citation:

---

Donc actuellement tjrs pareil avec revert ça marche pas

---

Encore une fois, git revert :

• Ne sert pas à faire disparaître le dernier commit en date (en coupant le haut de la branche, comme s'il n'avait jamais eu lieu), et…
• Ne sert pas non plus à annuler ce qui est en suspens dans l'index ou le répertoire de travail (de façon à retrouver un dépôt propre avec git status).

… mais :

• Sert à produire un nouveau commit dont l'effet est d'annuler les modifications introduites antérieurement par un autre commit.

Je pense que toute la confusion vient de là dès le départ. git revert sous Git va faire exactement la même chose que lorsque tu annules une modification d'une page de Wikipédia. Quand tu le fais, tu ne tronques pas l'historique : tu introduis une nouvelle modification, datée du jour et signée par toi, dont l'effet est de ramener la page à ce qu'elle était lors d'une révision antérieure. Et si tu examines le différentiel, tu t'aperçois que toutes les lignes vertes dans l'ancienne révision deviennent des lignes rouges dans la tienne et vice-versa.

Et tout revert qu'il est, ce nouveau commit introduit automatiquement reste un commit ordinaire. Donc, pour le produire, Git a besoin de l'index et pour cela, il faut que ton dépôt soit propre (qu'il n'y ait rien en suspens dedans). Si tu as des choses en suspens dans l'index, Git va te demander — à raison — soit de les enregistrer proprement au préalable (donc de faire ton propre commit d'abord), soit de les abandonner explicitement s'il n'y a pas lieu de les conserver, soit encore de les mettre de côté avec stash pour les reprendre plus tard (à condition de ne pas les oublier, ce qui arrive fréquemment avec cette commande).

Et — là encore — c'est à ne pas confondre avec la commande revert de Mercurial qui elle tronque l'historique, mais on n'entrera pas dans les détails ici.

Citation:

---

voilà ce que me répond les différentes commandes :

---

Bien.

Tu as donc trois commits en date (et en bonne et due forme). Tu as également mis en place un fichier .gitignore et porté une modification au fichier. Tu as ajouté ces deux fichiers à l'index avec git add et ils apparaissent donc en vert dans git status pour t'indiquer qu'ils seront enregistrés avec le prochain git commit. C'est d'ailleurs le sens du message « Changes to be committed ».

Citation:

---

D'après ce que j'ai lu dans tes infos, le git diff me dirais que j'ai modifié le git ignore à la ligne 1 en y ajoutant "DOC GIT.docx" ce qui est vrai,d'autre part il me signale que j'ai enlevé 3 lignes à partir de la ligne 1 et rajouter 2 lignes à partir de la ligne 1 ce qui est surement vrai même si j'ai je pense avoir modifié simplement la ligne 1...

---

Pas tout-à-fait. C'est le format de sortie de diff que tu vois ici. Donc même si cela concerne Git, tu les aurais eu également si tu avais utilisé directement la commande diff en dehors de tout contexte Git.

Il est dit ici que le bloc entier présenté sous « @@ », lignes de contexte comprises (il n'y en a pas dans cet exemple) commençait à la ligne 1 (en partant de 1) et comptait 3 lignes, et que désormais il commencera toujours à la ligne 1 mais ne comptera plus que deux lignes. Il faut aussi tenir compte des lignes vides et des retours à la ligne… Le compte n'est pas tout-à-fait exact mais je suppose que le copier-coller doit y être pour quelque chose.

Le nombre de lignes dépend des modifications que tu y fais, naturellement. La ligne de départ du bloc, elle, peut varier si d'autres blocs avant lui ont également été modifiés et ont changé en taille.

Citation:

---

Pourquoi il me demande de "comitter" revert.md (git status) alors que je l'ai déjà fais

---

Justement parce que tu ne l'as pas fait.

Plus précisément, tu as bien généré ton dernier commit « prepend content » puis tu as ajouté .gitignore et la modification portée à revert.md à l'aide de git add. Tu as donc commencé à recharger l'index (ou staging area) avec de nouvelles choses. Elles doivent donc d'abord faire l'objet d'un nouveau commit (ou être abandonnées).

C'est là l'une des principales forces de Git et c'est entre autre ce qui le rend si populaire : tu peux facilement choisir ce que tu veux enregistrer dans tes commits et, par conséquent, regrouper tes modifications en unités logiques, par thème, plutôt qu'être obligé de tout enregistrer à chaque fois.

Citation:

---

et que j'ai fais un revert pour annuler mon dernier commit(prepend content) ?

---

… lequel a échoué parce que l'index n'était pas vide.

Citation:

---

Voilà peux tu me dires aussi si j'ai eu raison de supprimer mon depot local directement dans windows sans passer par une commande git ?

---

Si c'est bien ce que tu voulais faire (te débarrasser du dépôt entier), alors oui, il est sûr de supprimer le répertoire entier (c'est-à-dire le répertoire parent de .git). Je ne crois pas qu'il y ait même une commande Git dédiée à l'auto-destruction d'un dépôt. Par contre, faire cela avec prudence car l'historique peut contenir beaucoup de données et si on supprime le tout par accident, il est très difficile voire impossible de le récupérer.

Bonjour j'ai fait deux autres commit maintenant mon dépot est propre(quand je parle de dépot, je veux dire après le staging aréa) :
Dossier local - Staging Aréa - Dépot local

Code:

---

1 2 3 4

$ git status On branch master nothing to commit, working tree clean

---

Donc sur mon dépot local j'ai :

Code:

---

1 2 3 4 5 6 7

$ git log --oneline 60787ff (HEAD -> master) modif4 c1b76d3 derniere modif 1902f1f prepend content d8b4545 initial content e901107 initial commit

---

Quand je fais diff ou diff cached il me renvoie rien.

Voilà maintenant puis je faire un revert pour annuler le dernier commit (modif4) ?

Citation:

---

Envoyé par xeron33

Voilà maintenant puis je faire un revert pour annuler le dernier commit (modif4) ?

---

Absolument.

Celui-ci ou un autre, d'ailleurs, mais je te laisse voir cela toi-même. ;)

bjr je viens de le faire voiçi ses réponses :

Code:

---

1 2 3 4 5

$ git revert HEAD error: your local changes would be overwritten by revert. hint: commit your changes or stash them to proceed. fatal: revert failed

---

Puis sur les autres commandes :

Code:

---

1 2 3 4 5 6 7

$ git log --oneline 60787ff (HEAD -> master) modif4 c1b76d3 derniere modif 1902f1f prepend content d8b4545 initial content e901107 initial commit

---

Code:

---

1 2 3 4 5 6 7 8 9

$ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: .gitignore deleted: DOC_GIT.docx deleted: gitignore modified: revert.md

---

Donc on a l'impression qu'il le fait puisqu'il crée un nouveau fichier .gitignore, puis il le supprime,il supprime le .docx et modifie le revert.md, mais malgrè tout me signale un message d'erreur à l'exécution du revert et ne créé pas non plus un autre commit pour inverser la donne si j'ai tout bien compris alors qu'à l'exécution du git status avant le revert tout allait bien...

Citation:

---

Envoyé par xeron33

bjr je viens de le faire voiçi ses réponses :

Code:

---

1 2 3 4 5

$ git revert HEAD error: your local changes would be overwritten by revert. hint: commit your changes or stash them to proceed. fatal: revert failed

---

---

Cela n'aurait pas dû arriver. Es-tu sûr que ton dépôt était rigoureusement propre avant de lancer la commande ou as-tu fait des modifications entretemps depuis ton dernier message ? Il n'est pas impossible, dans le premier cas, que la version que tu utilises comporte un bug mais ce serait quand même très étonnant. À verifier avec git --version.

Citation:

---

Code:

---

1 2 3 4 5 6 7 8 9

$ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) new file: .gitignore deleted: DOC_GIT.docx deleted: gitignore modified: revert.md

---

Donc on a l'impression qu'il le fait puisqu'il crée un nouveau fichier .gitignore, puis il le supprime,il supprime le .docx et modifie le revert.md, mais malgrè tout me signale un message d'erreur à l'exécution du revert et ne créé pas non plus un autre commit pour inverser la donne si j'ai tout bien compris alors qu'à l'exécution du git status avant le revert tout allait bien...

---

Attention, ce ne sont pas les mêmes : il efface gitignore (sans point initial) et crée en parallèle .gitignore (avec le point). Ce ne sont pas les mêmes fichiers. Peut-être as-tu renommé ton fichier, auquel cas il existe git mv pour lui faire faire lui-même, pour qu'il en soit ainsi averti.

Par ailleurs, il faut se méfier lorsque l'on supprime des fichiers dans l'historique. C'est tout-à-fait autorisé mais, à ce stade, le fichier cesse d'être suivi. Si tu le recrées ensuite, cela redevient un fichier non suivi ordinaire. Donc, Git n'y touche pas sauf si tu rappelles une ancienne version dans laquelle il existait, avec git checkout ou avec un revert.

Mais dans tous les cas, ça ne peux pas arriver dans un dépôt « propre » sauf si tu annules une version donnée qui a modifié une ligne elle-même modifiée ensuite par un autre commit entre les deux. Mais là encore, ce n'est pas possible si tu annules le dernier commit.

Si ton dépôt est vraiment un dépôt de test (et que l'on peut tout y casser sans risque), peux-tu tenter :

Code:

---

1 2	$ git reset --hard 60787ff $ git revert

---

… sans HEAD après revert, même si cela ne devrait rien changer.

Bjr,
Je suis reparti à zéro avec un nouveau dossier local :

Code:

---

1 2	$ touch revert.md

---

puis

Code:

---

1 2	$ git add revert.md

---

puis :

Code:

---

1 2 3 4 5 6 7 8 9

$ git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: revert.md

---

Code:

---

1 2 3

$ git log --oneline fatal: your current branch 'master' does not have any commits yet

---

normal j'ai rien "commité"

puis :

Code:

---

1 2 3 4 5

$ git commit -m "1ere info" [master (root-commit) 29dca35] 1ere info 1 file changed, 1 insertion(+) create mode 100644 revert.md

---

puis :

Code:

---

1 2 3 4

$ git status On branch master nothing to commit, working tree clean

---

puis :

Code:

---

1 2 3

$ git log --oneline 29dca35 (HEAD -> master) 1ere info

---

puis

Code:

---

1 2 3 4 5

$ git revert HEAD hint: Waiting for your editor to close the file... "C:\\Program Files (x86)\\Notepad++\\notepad++.exe" -multiInst -notabbar -nosession -noPlugin: line 1: C:\Program Files (x86)\Notepad++\notepad++.exe: No such file or directory error: There was a problem with the editor '"C:\\Program Files (x86)\\Notepad++\\notepad++.exe" -multiInst -notabbar -nosession -noPlugin'. Please supply the message using either -m or -F option.

---

et là j'ai tjrs ce message d'erreur par apport à Notepad++, je l'ouvre et le ferme et plus ce message mais...

Code:

---

1 2 3 4 5

$ git revert HEAD error: your local changes would be overwritten by revert. hint: commit your changes or stash them to proceed fatal: revert failed

---

Code:

---

1 2 3 4 5 6

$ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) deleted: revert.md

---

Donc j'en conclue qu'il supprime bien revert.md avec le revert mais ne fonctionne pas correctement, niveau version :

Code:

---

1 2 3

$ git --version git version 2.44.0.windows.1

---

Peut être un problème avec Notepad++ ?

Bonsoir,
J'utilise la version 2.44.0 également sous Linux, couplé à l'éditeur vim.

Effectivement, il semble que tu aies mis le doigt dessus. C'est bien l'éditeur qui semble poser problème ici.

En effet, un git revert recharge l'index avec le négatif du différentiel du commit à annuler et déclenche un nouveau commit en bonne et due forme pour le faire… en ouvrant l'éditeur et en proposant une page pré-remplie que l'utilisateur n'a plus qu'à compléter au besoin.

On voit ici que l'index est bien rempli avec ce que l'on attend ici mais normalement on ne le voit jamais puisque le commit est lancé dès que l'on quitte l'éditeur.

Je pense que notepad++ reste ouvert en arrière-plan et se contente d'ouvrir un onglet chaque fois qu'on l'invoque de l'extérieur. Il est possible que même en le refermant, il garde indûment un lock sur le fichier. Je te suggère effectivement d'essayer avec un autre éditeur pour voir si le problème persiste.

Un conseil également : le commit initial est particulier. Bien que cela fonctionne, je te suggère toutefois de faire au moins deux commits pour tes tests et de laisser inchangé le commit initial. Sinon, c'est aller au devant de difficultés supplémentaires qui s'ajouteront à celles que tu connais déjà et on s'en passerait bien volontiers.

Bjr,
J'ai tout repris en supprimant carrément notepad++ et en travaillant uniquement en ligne de commandes sans aucun éditeur et très curieusement tjrs le meme problème quand je lance git revert :

Code:

---

1 2 3 4 5

$ git revert HEAD hint: Waiting for your editor to close the file... "C:\\Program Files (x86)\\Notepad++\\notepad++.exe" -multiInst -notabbar -nosession -noPlugin: line 1: C:\Program Files (x86)\Notepad++\notepad++.exe: No such file or directory error: There was a problem with the editor '"C:\\Program Files (x86)\\Notepad++\\notepad++.exe" -multiInst -notabbar -nosession -noPlugin'. Please supply the message using either -m or -F option.

---

j'ai fait deux commit :

Code:

---

1 2 3 4

$ git log --oneline b952427 (HEAD -> master) 2ème info b352550 1ère info

---

Là j'avoue je me lasse...quand penses tu ?

Hello,

Quand on parlait de l'éditeur de Git, c'est celui qu'il lance automatiquement pour te permettre de rédiger les messages des commits, bien sûr. Tu peux tout-à-fait continuer à utiliser notepad++ en parallèle pour éditer tes sources.

L'éditeur que Git choisit lorsqu'il a besoin de te faire composer un message est soit déposé dans la configuration du dépôt sous core.editor, soit dans la variable d'environnement GIT_EDITOR. Voir ici et ici. Tu peux voir la liste des clés de configuration avec git config -l et afficher la variable d'environnement en ligne de commande avec echo %GIT_EDITOR%.

Par ailleurs, le fichier dont Git demande l'ouverture à l'éditeur porte toujours le même nom, mais n'est jamais le même par définition. Si l'éditeur ne le sait pas et le conserve en cache, tout en restant lui-même en vie, ça peut expliquer ce genre de problème d'accès concurrents.

Tu peux déjà demander à Git d'effectuer un revert sans ouvrir l'éditeur :

Code:

---

git revert --no-edit HEAD

---

Citation:

---

Envoyé par Obsidian

Par ailleurs, le fichier dont Git demande l'ouverture à l'éditeur porte toujours le même nom, mais n'est jamais le même par définition. Si l'éditeur ne le sait pas et le conserve en cache, tout en restant lui-même en vie, ça peut expliquer ce genre de problème d'accès concurrents.

Tu peux déjà demander à Git d'effectuer un revert sans ouvrir l'éditeur :

Code:

---

git revert --no-edit HEAD

---

---

bjr,
J'ai reessayé en modifiant le nom du fichier, ça marche tjrs pas,J'ai essayé

Code:

---

git revert --no-edit HEAD

---

ça ne change rien

j'ai essayé ta commande pour voir la config, il m'affiche tjrs notepad++ comme éditeur, alors que je l'ai supprimé...

Code:

---

1 2	core.editor="C:\\Program Files (x86)\\Notepad++\\notepad++.exe" -multiInst -notabbar -nosession -noPlugin

---

et j'ai un autre problèmes si tu pouvais m'aider, car je n'arrive pas à sortir du bash :

Code:

---

1 2

(END)

---

Je n'ai pas trouvé comment sortir de là à part fermer carement la fenêtre. D'autre part tu dis :

Citation:

---

Quand on parlait de l'éditeur de Git, c'est celui qu'il lance automatiquement pour te permettre de rédiger les messages des commits

---

Mais alors c'est lequel c'est quoi son nom ?

Bonjour,
Décidément, tu n'as pas de chance… et conséquemment, c'est tout à ton honneur de persévérer.

Citation:

---

Envoyé par xeron33

bjr,
J'ai reessayé en modifiant le nom du fichier, ça marche tjrs pas,

---

Ce n'est pas le fichier sur lequel tu travailles, dans le working directory, qui pose problème.

Lorsque Git t'invite à saisir un message, lors d'un commit ou d'un revert, il demande à l'éditeur d'ouvrir un fichier texte temporaire, généralement .git/COMMIT_EDITMSG, donc ouvert en dessous de .git. Ce fichier persiste jusqu'à ce que Git ait besoin de t'en faire remplir un nouveau, auquel cas il sera effacé puis recréé, d'où les considérations exposées au commentaire précédent.

Citation:

---

J'ai essayé

Code:

---

git revert --no-edit HEAD

---

ça ne change rien

---

Cette fois-ci, par contre, il n'y a plus rien qui devrait l'empêcher de fonctionner. Là encore, le dépôt était-il bien propre avant d'avoir lancé la commande ?

Citation:

---

j'ai essayé ta commande pour voir la config, il m'affiche tjrs notepad++ comme éditeur, alors que je l'ai supprimé...

---

Git n'est pas lié du tout à Notepad++ en lui-même, et ne suit pas le système d'installation de Windows pour le savoir non plus

Citation:

---

Code:

---

core.editor="C:\\Program Files (x86)\\Notepad++\\notepad++.exe" -multiInst -notabbar -nosession -noPlugin

---

---

La chaîne que tu vois après « = » est justement la commande que l'on demande à Git d'appeler pour ouvrir l'éditeur servant à rédiger le message en question. On remarque d'ailleurs que plusieurs options sont passées à Notepad++ justement pour éviter les problèmes évoqués plus haut.

Essaie de modifier le contenu de cette chaîne pour lui faire appeler le bloc-note ordinaire, par exemple.

Il est possible de passer ponctuellement une ou plusieurs clés de configuration spécifiques lorsque l'on appelle une commande Git. Si l'on veut les modifier durablement, on peut soit modifier directement le fichier config sous .git, soit appeler git config -e pour qu'il ouvre lui-même l'éditeur, mais comme ici c'est justement le problème qui nous occupe, on va la modifier directement avec la commande idoine.

Je te conseille de repartir une fois de plus sur un dépôt tout neuf, puis saisir dedans :

Code:

---

git config core.editor notepad.exe

---

… et refaire tes tests.

Si ça ne marche pas avec « notepad.exe » seul, tu peux essayer « C:\Windows\System32\notepad.exe » à la place, ou le chemin vers l'emplacement actuel du bloc-notes si tu peux le trouver sur ta machine.

Vérifie aussi que la variable d'environnement GIT_EDITOR soit bien effacée (ou positionnée à la même valeur) parce que je ne sais plus laquelle prend le pas sur l'autre dans cette situation.

Citation:

---

et j'ai un autre problèmes si tu pouvais m'aider, car je n'arrive pas à sortir du bash :

Code:

---

1 2

(END)

---

Je n'ai pas trouvé comment sortir de là à part fermer carement la fenêtre.

---

Ça dépend (et comme je ne travaille pas sous Windows, c'est encore plus difficile à dire), mais :

— Soit c'est vraiment le shell qui est encore actif et, dans ce cas, on en sort avec la commande exit ;
— Accessoirement, on peut faire Ctrl+D sous Unix ou Ctrl+Z sous Windows (de mémoire) pour indiquer au terminal qu'il n'y a plus rien à lire ;
— Soit c'est en fait le pager « less » qui te bloque et dans ce cas, tu dois pouvoir en sortir simplement avec la touche « q », ou éventuellement Ctrl+C pour interrompre le programme par un break (si la combinaison de touches n'est pas capturée par le copier-coller). C'est le cas le plus probable si tu vois « (END) » à la fin ;
— Soit c'est la fenêtre qui est configurée pour persister après la mort du processus.

Citation:

---

D'autre part tu dis :

Citation:

---

Quand on parlait de l'éditeur de Git, c'est celui qu'il lance automatiquement pour te permettre de rédiger les messages des commits

---

Mais alors c'est lequel c'est quoi son nom ?

---

Précisément celui dont on parle ci-dessus. Git, en principe, ne s'occupe que de l'état des fichiers suivis, pas de la façon dont tu le fais. Mais s'il doit te faire remplir un message, il faut qu'il ouvre un éditeur pour te permettre de le faire. Et la ligne de commande à appeler pour cela est précisément déposée dans la clé « core.editor », ce qui te permet de choisir celui qui te plaît. Généralement, on s'en tient à celui que l'on utilise couramment mais dans ton cas précis, il semble il y avoir des conflits qui demanderaient qu'on l'on puisse examiner ta configuration complète pour pouvoir faire un diagnostic.

bjr,

Citation:

---

Essaie de modifier le contenu de cette chaîne pour lui faire appeler le bloc-note ordinaire, par exemple.

Il est possible de passer ponctuellement une ou plusieurs clés de configuration spécifiques lorsque l'on appelle une commande Git. Si l'on veut les modifier durablement, on peut soit modifier directement le fichier config sous .git, soit appeler git config -e pour qu'il ouvre lui-même l'éditeur, mais comme ici c'est justement le problème qui nous occupe, on va la modifier directement avec la commande idoine.

Je te conseille de repartir une fois de plus sur un dépôt tout neuf, puis saisir dedans :

Code : Sélectionner tout - Visualiser dans une fenêtre à part

git config core.editor notepad.exe

… et refaire tes tests.

Si ça ne marche pas avec « notepad.exe » seul, tu peux essayer « C:\Windows\System32\notepad.exe » à la place, ou le chemin vers l'emplacement actuel du bloc-notes si tu peux le trouver sur ta machine.

Vérifie aussi que la variable d'environnement GIT_EDITOR soit bien effacée (ou positionnée à la même valeur) parce que je ne sais plus laquelle prend le pas sur l'autre dans cette situation.

---

J'ai essayé de modifier la variable core.editor comme tu me le dis, sur un depot tout neuf, mais quand je fais :

Code:

---

1 2	$ git config -l

---

j'ai toujours :

Code:

---

1 2	core.editor="C:\\Program Files (x86)\\Notepad++\\notepad++.exe" -multiInst -notabbar -nosession -noPlugin

---

Par contre sous .git dans le fichier config j'ai :

Code:

---

1 2 3 4 5 6 7 8 9

[core] repositoryformatversion = 0 filemode = false bare = false logallrefupdates = true symlinks = false ignorecase = true editor = C:WindowsSystem32notepad.exe

---

et depuis j'ai :

Code:

---

1 2 3 4 5

$ git revert -F HEAD hint: Waiting for your editor to close the file... error: cannot spawn C:WindowsSystem32notepad.exe: No such file or directory error: unable to start editor 'C:WindowsSystem32notepad.exe' Please supply the message using either -m or -F option.

---

J'ai modifié ce fichier avec bloc note en rajoutant les antislash :

Code:

---

1 2	C:\WindowsSystem32\notepad.exe

---

et il a pas aimé :

Code:

---

1 2 3

$ git status fatal: bad config line 8 in file .git/config

---

Mais quand je remet le config à l'origine bien sûr j'ai :

Code:

---

1 2 3 4 5

$ git revert -F HEAD hint: Waiting for your editor to close the file... error: cannot spawn C:WindowsSystem32notepad.exe: No such file or directory error: unable to start editor 'C:WindowsSystem32notepad.exe' Please supply the message using either -m or -F option.

---

J'ai vérifié dans windows les variables d'environnement j'ai pas vu GIT_EDITOR
J'ai remarqué aussi sauf erreur que quand je fais les modifs en ligne de commande, les modifs n'apparaissent pas dans windows ou il y a un décalage, du coup j'utilise notepad. Apparement le problème ne vient pas ne notepad++, j'ai pourtant bien validé mes modifs dans notepad en fermant l'onglet en cours car j'avais remarqué aussi que si on le faisant pas il restait des choses en suspend ou du moins quand on ouvrait l'éditeur...

Puis ensuite j'ai essayé

Code:

---

1 2	git revert --no-edit HEAD

---

ET là :) maintenant ça fonctionne !

Code:

---

1 2 3 4 5

$ git revert --no-edit HEAD [master 3ac20b0] Revert "7ème info" Date: Tue Apr 30 10:40:30 2024 +0200 1 file changed, 1 insertion(+), 1 deletion(-)

---

Code:

---

1 2 3 4

$ git status On branch master nothing to commit, working tree clean

---

avec bien la notation Revert "7ème info"

Code:

---

1 2 3 4 5 6 7 8 9 10 11

$ git log --oneline 3ac20b0 (HEAD -> master) Revert "7ème info" 9f36062 7ème info c19f974 6ème info 6f190fa Revert "5ème info" 176fbad 5ème info 5ec90d2 4ème info d480788 3ème info 6324fb7 2ème info f1e9562 1ère info

---

En fait sans :

Code:

---

1 2

--no-edit

---

Il fait bien la modif mais au niveau du status :

Code:

---

1 2 3 4 5 6

$ git status On branch master Changes to be committed: (use "git restore --staged <file>..." to unstage) modified: revert3.md

---

MERCI BEAUCOUP pour ton suivi !!! Ca fonctionne aussi avec notepad++
A+:)