Re: arranger.ly : mise à jour vers Lilypond 2.25.7 + quelques commentaires

[Jean Abou Samra]

Le vendredi 15 septembre 2023 à 10:21 +0200, Jean Abou Samra a écrit :

D'abord, tu cliques sur le bouton « Merge » dans la « pull request », ce qui met à jour la branche master sur GitHub. Ensuite, tu fais « git pull » dans ton dépôt local. Si tu as des commits en plus qui n'étaient pas sur GitHub, Git va faire une fusion entre les deux, et si tu as des modfications non committées, elles vont simplement se retrouver sur le nouvel état du dépôt. Simplement, il peut évidemment y avoir un conflit entre les deux, auquel cas Git te demandera de le résoudre.

Ah, et j'oubliais une chose. Si tu as des modifications non committées, alors la notion de conflit devient plus stricte. En fait, Git refusera le pull si tu as modifié un fichier, sans committer ces modifications, et que les commits ajoutés par le pull modifient le même fichier, même si ce n'est pas au même endroit et qu'une fusion pourrait être faite (il te dira « erreur : Vos modifications locales aux fichiers suivants seraient écrasées par la fusion : ... »). Dans ce cas-là, tu as deux options :

a) committer les modifications et relancer le git pull

b) « git stash » pour « remiser » temporairement les modifications, puis « git pull », puis « git stash pop » pour réappliquer les modifications temporairement remisées

La raison à ça est plutôt subtile. Supposons que le fichier de départ soit

A

B

B

B

C

que ta modification locale soit

A

D <- tu as ajouté cette ligne

B

B

B

C

et que le changement fait sur GitHub soit

A

<les lignes B sont supprimées>

C

Alors les deux changements peuvent parfaitement être fusionnés, cela donne

A

D <- ajout de cette ligne

<suppression des lignes B>

C

Mais maintenant, modifions le scénario pour que ta modification soit

A

B

B

B

D <- cette fois, tu as ajouté la ligne D après les B

C

Alors, la fusion est

A

<suppression des B>

D <- ajout du D

C

qui est exactement le même fichier

A

D

C

Moralité : Git refuse la fusion automatique dans ce cas parce que dans certains cas, elle n'est pas réversible, et Git fait beaucoup, beaucoup d'efforts pour que tu ne perdes jamais ton travail, que tu puisses toujours revenir en arrière, et ça risquerait de ne pas être le cas.

Alors que quand tu fais d'abord un commit de ton travail, l'état ancien reste accessible dans l'historique, avec ce commit.

Bref, c'est l'un des aspects les moins intuitifs de Git, il faut juste être au courant. En résumé, si Git refuse une fusion avec des changements non committés, ça marche souvent après avoir committé.

Jean

signature.asc
Description: This is a digitally signed message part