Discussion :

[vmonteco]

Bonjour!

J'essaie de faire des expériences avec git pour mieux l'exploiter.
Je me retrouve aujourd'hui face à une question à laquelle je n'ai pas la réponse.

J'ai deux dépôts git pour un seul projet. Chacun de ces dépôts est sur une machine différente et communique par ssh avec l'autre.
Les deux dépôts sont identiques et les branches de l'un se retrouvent toutes sur l'autre.
Lorsque je me mets sur une branche et que je fais des modifications, que je fait mon commit, puis que je fais un push de la branche courante vers la branche correspondante sur le dépôt distant, les modifications n'apparaissent pas dans le répertoire de travail si il est sur la branche en question.
J'ai pu voir que les modifications avaient été enregistrées puisqu'elles apparaissent dans un git show sur le dépôt distant en question.
Toujours sur le dépôt distant, l'ancien état est toujours apparent mais compté comme une modification (il y a des changements à commiter) :
-Si je fais le commit je retombe sur l'état initial (avant les modifications).
-Si je fais un stash j'obtiens le nouvel état avec les modifications que j'ai apportées.

J'ai un peu de mal à comprendre ce comportement.
Je pensais que lorsque je faisais mon push, le répertoire de travail était mis à jour mais ce n'est pas le cas apparemment.

Quelqu'un aurait-il une petite explication pour le débutant que je suis?

Merci d'avance!

[Obsidian]

Bonjour,

Essaie de faire un « git status » avant le commit pour voir ce qui a changé, et ce qui va réellement être pris en compte ou pas. Contrairement à Mercurial, Git ne prend pas automatiquement dans ses commits les modifications apportées aux fichiers qui font déjà partie de l'arbre. Heureusement, il reste très aisé de lui dire de le faire.

Bon courage.

[vmonteco]

Sur le dépôt distant tu veux dire?

Soient A le dépôt local (où le travail a été effectué) et B le dépôt distant.

Eh bien sur B on dirait que les modifications ont bien été enregistrées.
Du coup :
-Sur B le dernier état commité est le nouvel état (celui qui vient de A).
-Sur B l'état du répertoire de travail est l'état antérieur à ces modifications venant de A.
-Sur B l'état du répertoire de travail est différent du dernier commit (venant de A), les différences sont donc présentées comme des modifications.
-Les états sont "inversés" dans leur ordre, le nouvel état (venant de A) est considéré comme l'ancien, et l'ancien (état actuel du répertoire de travail sur B) est considéré comme le nouveau, ce qui ne correspond pas à l'ordre dans lequel ils ont été codés.

Le git stash permet donc d'annuler ces modifications et de retourner au dernier état commité. Il permet donc d'abandonner l'état actuel du répertoire de travail (ancienne version) pour aboutir au nouveau (codé sur A).
C'est comme si ayant commité le nouvel état j'avais manuellement apporté les modifications nécessaires pour retrouver le précédent état.

Ce que je cherche à savoir c'est si il est possible de mettre à jour le répertoire de travail distant.

[LittleWhite]

Bonjour,

J'ai beau lire de nombreuses fois votre premier ou second message, je ne comprend rien
Le stash : http://git-scm.com/book/en/Git-Tools-Stashing

Stash, c'est une remise, un abri, un appentis. Lorsque vous bossez, vous faites une modification sur votre branche locale, mais personne n'est au courant, c'est normal. Vous ne voulez pas faire de commit, car vos modifications ne sont pas terminées (vous bossez dessus), mais vous souhaitez tout de même changer de branche (vous avez un bogue à corriger sur une release ou autre), si vous faites un git checkout, git vous jette (moi il le fait tout le temps ), car vous avez des modifications non commités. Alors, vos modifications, vous les mettez dans la remise (sous le tapis quoi). Votre branche locale revient à l'état initial de la branche et à partir de là, vous pouvez faire votre checkout (ou autre au final). Une fois que vous avez fini, vous pouvez revenir sur votre branche et ressortir vos modifications de la remise.
Donc, on reprends :
git clone -> copie d'un projet
git checkout -> changement de branche
git pull -> on récupère la dernière version de la branche qui est dispo sur le serveur (je pense que vous zappez énormément cette commande actuellement)
git commit -> on inscrit ses changements dans la branche locale
git push -> on envoie ses changements sur la branche sur le serveur (bien sur, un git pull est nécessaire au préalable)
git stash -> on fout son travail actuel dans une remise pour nettoyer sa branche locale, sans rien perdre.

[vmonteco]

Je vais essayer de reprendre en étant un peu plus clair avec un exemple concrret. :S

J'ai deux dépôts A et B.
Ils ont chacun une branche "branch".

A/branch suit B/branch

Au départ A/branch et B/branch ont tous deux un seul fichier file1.
Ce fichier est vide.
Je me place sur le dépôt A, sur la branche branch.
J'ajoute une ligne "test" dans file1.
Je fais un commit de la modification en étant toujours sur A/branch et je fais un push vers B (donc B/branch).

Maintenant je vais en B/branch.
Je me rends compte que le fichier file1 dans le répertoire de travail est toujours vide.
Il est cependant considéré comme modifié. La modification apportée à ce fichier file1 semble être la suppression de la ligne contenant "test".

En fait je pense avoir un début d'explication :
Après le dernier push depuis A vers B, le dernier commit enregistré dans B est celui provenant de A et correspondant à l'ajout de la ligne "test" dans file1.
Cependant la version de file1 se trouvant dans le répertoire de travail de B n'a toujours pas été mis à jour et est toujours vide, son état actuel dans le répertoire de travail correspond en fait à celui qu'il avait l'avant-dernier commit et non le dernier commit (celui avec l'ajout de la ligne "test" dans file1).
Et ce décalage apparaît comme une modification depuis le dernier commit, c'est à dire comme la suppression de la ligne "test" dans file1.
Pour git, j'ai supprimé cette ligne après le commit, un git stash me remet donc au dernier état commité et fait d'une certaine manière une MAJ du répertoire de travail puisque la ligne ajoutée dans le fichier apparaît enfin dans le répertoire de travail de B.

CEPENDANT :
La modification est bien prise en compte, si je fais un git clone du dépôt et que je me place sur la branche branch le fichier file1 contiendra bien la ligne "test".

En fait j'ai l'impression que lorsque je fais un push vers une branche d'un dépôt distant, le push est bien pris en compte mais le répertoire de travail ne semble pas mis à jour.

Je me demandais justement si il n'y avait pas moyen de faire en sorte que le répertoire de travail soit mis à jour pour éviter d'avoir à me connecter sur le serveur hébergeant le dépôt en question pour ne pas avoir à faire le git stash manuellement.

Voilà j'ai fait de mon mieux pour être clair mais j'avoue que je trouve ça assez difficile pour ce problème, désolé. :S

[Obsidian]

Je vais peut-être dire une grosse ânerie mais as-tu pensé à faire un « checkout » dans le dépot B ?

En fait j'ai l'impression que lorsque je fais un push vers une branche d'un dépôt distant, le push est bien pris en compte mais le répertoire de travail ne semble pas mis à jour.

C'est exactement ça et c'est normal puisque le dépôt de destination peut être un répertoire de travail au même titre que le répertoire source. Tu n'aurais donc pas envie que quelqu'un écrase tes modifications à distance avant que tu aies eu le temps de faire un commit et/ou de les fusionner.

« git checkout [commit] » te permet de mettre ton dépôt dans l'état correspondant à un commit donné. L'option « -f » (force) te permet en plus de forcer la mise à jour des fichiers concernés même s'ils ont été modifiés de leur côté (en temps normal, sans cette option, git a le bon goût de ne pas écraser les modifications manifestes qui n'ont pas encore été sauvegardées).

[vmonteco]

Je vais peut-être dire une grosse ânerie mais as-tu pensé à faire un « checkout » dans le dépot B ?
« git checkout [commit] » te permet de mettre ton dépôt dans l'état correspondant à un commit donné. L'option « -f » (force) te permet en plus de forcer la mise à jour des fichiers concernés même s'ils ont été modifiés de leur côté (en temps normal, sans cette option, git a le bon goût de ne pas écraser les modifications manifestes qui n'ont pas encore été sauvegardées).

Effectivement l'option -f arrange le soucis Sans elle j'avais simplement un message d'erreur "already on 'branch'" et je ne voyais pas comment mettre à jour le répertoire de travail.

Sujet résolu donc! Merci