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

From: Gilles Thibault <[email-masked]>
Date: Tue, 12 Sep 2023 15:11:07 +0200

La mise à jour d'arranger.ly pour les dernières versions de arranger.ly 
a été mise en ligne. Liens de téléchargements en bas de page.

C'est surtout une mise à jour, mais il y a une nouveauté pour la gestion 
des "modes" Lilypond ( les \drummode, \lyricmode etc...). Elle permet 
d'alléger la syntaxe, par exemple pour ceux qui ont beaucoup de percus 
dans leur arrangement.
Voir
    
http://gillesth.free.fr/Lilypond/arranger.ly-2.25.7/DOCS/arrangerDoc-fr.pdf
    (milieu page 36)

*******

Les commentaires que je voulais faire concernent l'organisation de la 
gestion partagée du code source d'arranger.ly et se résument en 1 phrase 
:

    ** Je suis totalement incompétent comme administrateur git et github 
**

Pour le patch qu'a proposé Jean Abou-Samra, j'ai simplement, à la 
sauvage, copié le code modifié dans ma propre version d'arranger.ly. 
github affiche maintenant :

    "This branch has conflicts that must be resolved"

J'ai tout un bagage de connaissances à acquérir et je vais devoir 
probablement revoir toute ma manière de procéder ("mom flux de 
travail").
Comme je ne suis pas un rapide, ça risque d'être un peu long.
Merci d'avances de votre patience.

Bon tests néanmoins.
À bientôt.

******************** LIENS ******************

-> Github :
https://github.com/gilles-th/arranger.ly

-> Accès direct :
http://gillesth.free.fr/Lilypond/arranger.ly-GIT-copy/arranger.ly-2.25.7.zip

-> En ligne de commande avec wget :
(les fichiers principaux de arranger.ly dans un répertoire arranger.ly 
dans le répertoire courant)
wget -m -A ly,pdf --no-host-directories --cut-dirs=1 --no-parent 
http://gillesth.free.fr/Lilypond/arranger.ly-2.25.7/

-- 
Gilles

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 13 Sep 2023 14:19:19 +0200

Utilisateur de git journalièrement, comment puis-je t’être utile ?
Papilip

> Le 12 sept. 2023 à 15:11, Gilles Thibault <[email-masked]> a écrit :
> 
> La mise à jour d'arranger.ly pour les dernières versions de arranger.ly a été mise en ligne. Liens de téléchargements en bas de page.
> 
> C'est surtout une mise à jour, mais il y a une nouveauté pour la gestion des "modes" Lilypond ( les \drummode, \lyricmode etc...). Elle permet d'alléger la syntaxe, par exemple pour ceux qui ont beaucoup de percus dans leur arrangement.
> Voir
> Les commentaires que je voulais faire concernent l'organisation de la gestion partagée du code source d'arranger.ly et se résument en 1 phrase :
> 
>   ** Je suis totalement incompétent comme administrateur git et github **
> 
> Pour le patch qu'a proposé Jean Abou-Samra, j'ai simplement, à la sauvage, copié le code modifié dans ma propre version d'arranger.ly. github affiche maintenant :
> 
> J'ai tout un bagage de connaissances à acquérir et je vais devoir probablement revoir toute ma manière de procéder ("mom flux de travail").
> (les fichiers principaux de arranger.ly dans un répertoire arranger.ly dans le répertoire courant)
> wget -m -A ly,pdf --no-host-directories --cut-dirs=1 --no-parent http://gillesth.free.fr/Lilypond/arranger.ly-2.25.7/
> 
> 
> 
> 
> -- 
> Gilles
>

---

From: Gilles Thibault <[email-masked]>
Date: Thu, 14 Sep 2023 22:53:04 +0200

> Utilisateur de git journalièrement, comment puis-je t’être utile ?

Jusqu'à présent, je modifie le code chez moi en prenant le temps de le 
tester tranquillement sur mes projets en cours. Quand je pense que c'est 
prêt, je met à jour ma version git locale et je la pousse sur github 
directement sur le master (bon ça c'est peut-être un tort, faut me 
dire). J'ai un petit memo qui me rappelle toutes les commandes git à 
effectuer, car comme je les pratique pas souvent, je les oublie...

Si quelqu'un propose un patch, je dois faire comment ? Je ne parle pas 
de la version qui se trouve sur github (je ne connais pas encore la 
commande pour incorporer le patch, mais bon, je pense que je la 
trouverai facilement), je parle de ma version que j'utilise chez moi. 
Comment je la met à jour en incluant le patch mais sans effacer mes 
modifications ?

-- 
Gilles

---

From: Jean Abou Samra <[email-masked]>
Date: Fri, 15 Sep 2023 10:21:53 +0200

Le jeudi 14 septembre 2023 à 22:53 +0200, Gilles Thibault a écrit :
> dire).

Non non, c'est tout à fait normal.

> J'ai un petit memo qui me rappelle toutes les commandes git à 

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.

Cordialement,
Jean

---

From: Jean Abou Samra <[email-masked]>
Date: Fri, 15 Sep 2023 10:38:44 +0200

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