Subject: Sondage : Qui est utilise “git” en complément de sont travail d'écriture de partition

From: Philippe Nenert <[email-masked]>
Date: Fri, 23 Nov 2012 10:18:26 +0100

Bonjour,

Pour rebondir sur le précédent fil et avancer, je souhaiterai savoir qui utilise “git”* pour sauvegarder et/ou publier son travail d'écriture de partition.

Voudriez-vous répondre simplement 
OUI	=> utilisateur occasionnel ou régulier
NON 	=> ne l'utilise pas et ne le souhaite pas
Pourquoi pas => je ne le connais peu ou pas, mais ce serait une bonne idée.

L'idée du github pour lily fait son chemin,
Merci d'avance de vos réponses
Philippe

* https://fr.wikipedia.org/wiki/Git

---

From: Jean-Jacques gerbaud <[email-masked]>
Date: Fri, 23 Nov 2012 10:35:45 +0100

> Bonjour,
bonjour également,
> Pourquoi pas => je ne le connais peu ou pas, mais ce serait une bonne idée.
Je ne connais absolument pas git mais sii c'est facile d'accès, avec des 
règles accessibles, "pourquoi pas" pour moi !

> Merci d'avance de vos réponses

Voici la mienne ! :-)

-- 
JJG

Linux ? Y a moins bien mais c'est plus cher !
http://www.radiosuisseclassique.ch/fr

---

From: Benjamin Coudrin <[email-masked]>
Date: Fri, 23 Nov 2012 10:38:29 +0100

OUI

2012/11/23 Jean-Jacques gerbaud <[email-masked]>

>> Pour rebondir sur le précédent fil et avancer, je souhaiterai savoir qui
>> utilise “git”* pour sauvegarder et/ou publier son travail d'écriture de
>> partition.
>>
> http://www.**radiosuisseclassique.ch/fr<http://www.radiosuisseclassique.ch/fr>
>
>
> ______________________________**_________________
> liste de diffusion lilypond-user-fr
> [email-masked]
> https://lists.gnu.org/mailman/**listinfo/lilypond-user-fr<https://lists.gnu.org/mailman/listinfo/lilypond-user-fr>
>

-- 
Benjamin Coudrin
[email-masked]
(+33)6.09.11.00.83

---

From: Pierre Perol-Schneider <[email-masked]>
Date: Fri, 23 Nov 2012 10:41:00 +0100

Idem que Jean-Jacques : je ne connais pas mais pourquoi pas

Le 23 novembre 2012 10:38, Benjamin Coudrin <[email-masked]> a
écrit :

> _______________________________________________
> https://lists.gnu.org/mailman/listinfo/lilypond-user-fr
>
>

---

From: bameylan <[email-masked]>
Date: Fri, 23 Nov 2012 01:48:51 -0800 (PST)

Pourquoi pas => je ne le connais peu ou pas

-----
Cordialement

Bernard
--
View this message in context: http://lilypond-french-users.1298960.n2.nabble.com/Sondage-Qui-est-utilise-git-en-complement-de-sont-travail-d-ecriture-de-partition-tp7578711p7578715.html
Sent from the LilyPond French Users mailing list archive at Nabble.com.

---

From: nyko <[email-masked]>
Date: Fri, 23 Nov 2012 02:12:13 -0800 (PST)

je ne l'utilise pas mais je pensais justement m'y mettre.
J'ai vu qu'il était question d'un support de "git" dans le TODO de
frescobaldi (/support for Git/Hg/Svn diff/revert/commit/)

Philippe Nenert wrote

> lilypond-user-fr@

--
View this message in context: http://lilypond-french-users.1298960.n2.nabble.com/Sondage-Qui-est-utilise-git-en-complement-de-sont-travail-d-ecriture-de-partition-tp7578711p7578716.html
Sent from the LilyPond French Users mailing list archive at Nabble.com.

---

From: Michel Villeneuve <[email-masked]>
Date: Fri, 23 Nov 2012 11:31:10 +0100

OUI

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 23 Nov 2012 12:44:27 +0100

> * https://fr.wikipedia.org/wiki/Git

https://github.com/horndude77/open-scores

Bien cordialement,
~Mike

---

From: François Martin <[email-masked]>
Date: Fri, 23 Nov 2012 13:04:52 +0100

Pourquoi

Le 23 novembre 2012 12:44, [email-masked] <[email-masked]> a

---

From: Frédéric Bron <[email-masked]>
Date: Fri, 23 Nov 2012 15:32:51 +0100

> Pour rebondir sur le précédent fil et avancer, je souhaiterai savoir qui utilise “git”* pour sauvegarder et/ou publier son travail d'écriture de partition.
OUI, indispensable pour moi.
Frédéric

---

From: Martial <[email-masked]>
Date: Fri, 23 Nov 2012 15:35:13 +0100

je ne le connais pas, a voir ...

-- 
Martial

---

From: Seventies <[email-masked]>
Date: Fri, 23 Nov 2012 07:45:39 -0800 (PST)

Du même avis : je ne connais pas, mais ça pourrait aider

--
View this message in context: http://lilypond-french-users.1298960.n2.nabble.com/Sondage-Qui-est-utilise-git-en-complement-de-sont-travail-d-ecriture-de-partition-tp7578711p7578723.html
Sent from the LilyPond French Users mailing list archive at Nabble.com.

---

From: Bertrand Bordage <[email-masked]>
Date: Fri, 23 Nov 2012 18:30:02 +0100

Bonjour,

(N'ayant pas suivi toute la discussion, il est possible que j'écrive des
choses déjà énoncées)

J'utilise bien entendu git en tant que développeur de divers projets.  Mais
je fais de même pour tous mes travaux LilyPond, LaTeX, Inkscape,
LibreOffice, etc.
C'est pour moi une assurance de pérennité et une façon d'encadrer
proprement son travail (à chaque petite ou large tâche on relit facilement
ses changements puis on y associe un message).
L'outil indispensable pour tout scientifique à mon avis.

Je conseille aussi Mercurial (dont le diminutif est "hg"), moins performant
et complet que git, mais plus facile pour un débutant et également plus
ergonomique.  Il a la même philosophie que git et n'a donc lui aussi rien à
voir avec Subversion (que je déconseille fortement).

Et bien sûr les excellents :

   - github pour mettre en ligne ses projets git (publics uniquement à
   moins de payer)
   - bitbucket les projets git et Mercurial.  S'il est un peu moins complet
   que github, on peut y mettre autant de dépôts privés qu'on le souhaite sans
   avoir à payer.  Un gros point fort, donc.

Bertrand

---

From: Jean-Jacques Gerbaud <[email-masked]>
Date: Fri, 23 Nov 2012 21:14:57 +0100

> Bonjour,
Bonjour Bertrand,
> (N'ayant pas suivi toute la discussion, il est possible que j'écrive des
non, pas du tout, rien n'a été énoncé, du moins dans ce que tu nous dis 
dans la suite de ton message.
>
> J'utilise bien entendu git en tant que développeur de divers projets.
>   Mais je fais de même pour tous mes travaux LilyPond, LaTeX, Inkscape,
> LibreOffice, etc.
> proprement son travail (à chaque petite ou large tâche on relit
> facilement ses changements puis on y associe un message).
...........

Tu as l'air calé en Git et on t'invite à nous donner notre première 
leçon car j'avoue que je suis assez admiratif d'utiliser Git pour tous 
tes travaux personnels (Lilypond, LibreOffice, etc...) et je voudrais 
bien comprendre ta manière de travailler.

Je suis allé là : > 
http://git-scm.com/book/fr/D%C3%A9marrage-rapide-Param%C3%A9trage-%C3%A0-la-premi%C3%A8re-utilisation-de-Git

et ai fait les premières manips pour que Git soit installé sur ma machine.

Mais ...maintenant ?

On attend la suite.

-- 
JJG

---

From: Bertrand Bordage <[email-masked]>
Date: Fri, 23 Nov 2012 22:25:42 +0100

Le 23 novembre 2012 21:14, Jean-Jacques Gerbaud <[email-masked]> a
écrit :

> Tu as l'air calé en Git et on t'invite à nous donner notre première leçon
> car j'avoue que je suis assez admiratif d'utiliser Git pour tous tes
> travaux personnels (Lilypond, LibreOffice, etc...) et je voudrais bien
> comprendre ta manière de travailler.
>
> Je suis allé là : > http://git-scm.com/book/fr/D%**
> C3%A9marrage-rapide-Param%C3%**A9trage-%C3%A0-la-premi%C3%**
> A8re-utilisation-de-Git<http://git-scm.com/book/fr/D%C3%A9marrage-rapide-Param%C3%A9trage-%C3%A0-la-premi%C3%A8re-utilisation-de-Git>
>

Maintenant il faut apprendre les quelques commandes de base.  Git ayant été
paramétré, il faut maintenant créer un "dépôt".  C'est le nom donné au
répertoire dont on va suivre les changements.
Pour créer un dépôt :

   1. Dans un terminal, se placer dans le répertoire où on souhaite créer
   avec la commande cd /repertoire/a/surveiller (évidemment, c'est
   uniquement si le répertoire existe déjà).
   2. Exécuter git init

Ensuite il faut comprendre le cycle de travail commun à tous les logiciels
de gestion de version.  Voilà le principe :

   1. On modifie les fichiers qu'on souhaite en essayant d'éviter de faire
   trop de modifications à la fois (sans quoi la relecture est hardue).
   2. On regarde le "diff" qui indique tous les changements ayant été faits
   sur des fichiers.
   3. On sélectionne les changements qui vont constituer le "commit" de
   l'étape suivante (étape facultative si toutes les modifications sont à
   prendre en compte).
   4. On fait un "commit".  C'est un genre d'enregistrement de tous les
   changements effectués depuis le dernier commit auquel on ajoute un message
   compréhensible comme "Ajout de la partie de basse continue dans le concerto
   RV 123".
   5. Si on a un dépôt distant (une copie sur internet de ce dépôt quoi),
   on peut vouloir faire une synchronisation avec ce dépôt distant.

Si cette façon de travailler est indispensable pour un groupe de
développeur ou un développeur isolé, elle n'en est pas moins très utile
pour n'importe qui d'autre.  L'avantage n°1 c'est la disparition des
syndromes :

   - "Ah zut, ça marchait avant, je ne sais pas ce que j'ai fait mais ça ne
   marche plus" et
   - "Ah, ça marche.  Je fais une copie de ce fichier/répertoire avec la
   date pour être sûr de pouvoir la retrouver quand j'aurais changé des trucs"
   - "Bon, j'ai bloqué pendant quelques heures sur ce problème.  J'ai fait
   plein de changements mais ne sais plus trop où j'en suis.  Cela marche à
   peu près mais je ne suis pas sûr de savoir pourquoi."

Voilà typiquement la façon dont on se sert de git pour un projet LilyPond
tout neuf :

   1. mkdir essai_lilypond
   2. cd essai_lilypond
   3. git init
   4. On créé un fichier essai.ly dans lequel on met un système d'une portée
   5. git add essai.ly (cette commande permet de dire à git : "commence à
   suivre ce fichier" sans quoi il l'ignore totalement ; il ignorera donc les
   fichiers compilés genre PDF et MIDI, à moins que vous ne les ajoutiez avec
   cette même commande ; ce qui est à éviter, on préfère toujours ne garder
   que la source)
   6. git commit -m "Début de l'essai de partition avec un système tapée."
   7. On tape le second système
   8. git diff (montre avec des + et - ce qui a changé depuis qu'on a fini
   de taper le premier système)
   9. git add essai.ly (ce fichier avait déjà été ajouté ; cette commande
   sert désormais à dire de prendre ce changement en compte pour le prochain
   commit)
   10. git commit -m "Second système saisi."

On aurait pu aussi sauter l'étape 9 et ajouter l'argument -a pour dire "on
prend en compte tous les changements de fichiers ajoutés déjà une fois".
Bon, je n'explique pas encore comment utiliser un dépôt distant.  Je
conçois que cela peut déjà être perturbant comme façon de travailler.  Mais
je vous garantis que cela vaut son pesant d'or si vous arrivez à commencer
à vous en servir !

Avec des commandes plus avancées vous pouvez faire plein de choses :
annuler n'importe quel changement, même lointain, en une commande,
travailler en parallèle sur plusieurs choses sans qu'elles interagissent,
mettre des changements de côté et les reprendre plus tard, faire fusionner
automatiquement plusieurs changements, etc.  Et bien sûr, un avantage
majeur : pouvoir rendre tout son travail plus compréhensible par n'importe
qui passant derrière.  C'est ainsi vous assurer que vous pourrez mourir
n'importe quand : votre travail pourra être poursuivi par quelqu'un d'autre.

Bon, enfin vous l'aurez compris, c'est pas supra simple mais ça vaut l'coup.
A plus,
Bertrand

---

From: Remy CLAVERIE <[email-masked]>
Date: Sun, 25 Nov 2012 12:47:03 +0100 (CET)

Bonjour à tous,

Je crois qu'il faudrait aussi un site qui réperttorie tous les projets GIT pour 1) ne pas avoir de projets redondants 2) permette à celui qui est intéressé de se joindre au GIT.

Merci

Rémy

> Message du 23/11/12 22:41
> De : "Bertrand Bordage" 
> A : "Jean-Jacques Gerbaud" 
> Copie à : "lilypond-user-fr" 
> Objet : Re: Sondage : Qui est utilise “git” en complément de sont travail d'écriture de partition
> 
> Le 23 novembre 2012 21:14, Jean-Jacques Gerbaud  a écrit :
>

Tu as l'air calé en Git et on t'invite à nous donner notre première leçon car j'avoue que je suis assez admiratif d'utiliser Git pour tous tes travaux personnels (Lilypond, LibreOffice, etc...) et je voudrais bien comprendre ta manière de travailler.
> 
> Je suis allé là : > http://git-scm.com/book/fr/D%C3%A9marrage-rapide-Param%C3%A9trage-%C3%A0-la-premi%C3%A8re-utilisation-de-Git
> 

Maintenant il faut apprendre les quelques commandes de base.  Git ayant été paramétré, il faut maintenant créer un "dépôt".  C'est le nom donné au répertoire dont on va suivre les changements.
Pour créer un dépôt :

Dans un terminal, se placer dans le répertoire où on souhaite créer avec la commande cd /repertoire/a/surveiller (évidemment, c'est uniquement si le répertoire existe déjà).
Exécuter git init

Ensuite il faut comprendre le cycle de travail commun à tous les logiciels de gestion de version.  Voilà le principe :

On modifie les fichiers qu'on souhaite en essayant d'éviter de faire trop de modifications à la fois (sans quoi la relecture est hardue).
On regarde le "diff" qui indique tous les changements ayant été faits sur des fichiers.
On sélectionne les changements qui vont constituer le "commit" de l'étape suivante (étape facultative si toutes les modifications sont à prendre en compte).
On fait un "commit".  C'est un genre d'enregistrement de tous les changements effectués depuis le dernier commit auquel on ajoute un message compréhensible comme "Ajout de la partie de basse continue dans le concerto RV 123".
Si on a un dépôt distant (une copie sur internet de ce dépôt quoi), on peut vouloir faire une synchronisation avec ce dépôt distant.

Si cette façon de travailler est indispensable pour un groupe de développeur ou un développeur isolé, elle n'en est pas moins très utile pour n'importe qui d'autre.  L'avantage n°1 c'est la disparition des syndromes :

"Ah zut, ça marchait avant, je ne sais pas ce que j'ai fait mais ça ne marche plus" et
"Ah, ça marche.  Je fais une copie de ce fichier/répertoire avec la date pour être sûr de pouvoir la retrouver quand j'aurais changé des trucs"
"Bon, j'ai bloqué pendant quelques heures sur ce problème.  J'ai fait plein de changements mais ne sais plus trop où j'en suis.  Cela marche à peu près mais je ne suis pas sûr de savoir pourquoi."

Voilà typiquement la façon dont on se sert de git pour un projet LilyPond tout neuf :

mkdir essai_lilypond
cd essai_lilypond
git init
On créé un fichier essai.ly dans lequel on met un système d'une portée
git add essai.ly (cette commande permet de dire à git : "commence à suivre ce fichier" sans quoi il l'ignore totalement ; il ignorera donc les fichiers compilés genre PDF et MIDI, à moins que vous ne les ajoutiez avec cette même commande ; ce qui est à éviter, on préfère toujours ne garder que la source)
git commit -m "Début de l'essai de partition avec un système tapée."
On tape le second système
git diff (montre avec des + et - ce qui a changé depuis qu'on a fini de taper le premier système)
git add essai.ly (ce fichier avait déjà été ajouté ; cette commande sert désormais à dire de prendre ce changement en compte pour le prochain commit)
git commit -m "Second système saisi."

On aurait pu aussi sauter l'étape 9 et ajouter l'argument -a pour dire "on prend en compte tous les changements de fichiers ajoutés déjà une fois".

Bon, je n'explique pas encore comment utiliser un dépôt distant.  Je conçois que cela peut déjà être perturbant comme façon de travailler.  Mais je vous garantis que cela vaut son pesant d'or si vous arrivez à commencer à vous en servir !

Avec des commandes plus avancées vous pouvez faire plein de choses : annuler n'importe quel changement, même lointain, en une commande, travailler en parallèle sur plusieurs choses sans qu'elles interagissent, mettre des changements de côté et les reprendre plus tard, faire fusionner automatiquement plusieurs changements, etc.  Et bien sûr, un avantage majeur : pouvoir rendre tout son travail plus compréhensible par n'importe qui passant derrière.  C'est ainsi vous assurer que vous pourrez mourir n'importe quand : votre travail pourra être poursuivi par quelqu'un d'autre.

---

From: Bertrand Bordage <[email-masked]>
Date: Sun, 25 Nov 2012 16:09:12 +0100

Hello,

Le 25 novembre 2012 12:47, Remy CLAVERIE <[email-masked]> a écrit :

> Je crois qu'il faudrait aussi un site qui réperttorie tous les projets GIT
> pour 1) ne pas avoir de projets redondants 2) permette à celui qui est
> intéressé de se joindre au GIT.
>

Pour le point 2, c'est le principe à la base de github et bitbucket.  Il
n'y a même pas besoin de demander à l'auteur d'un projet pour faire des
modifications.  Si on souhaite en faire, un "fork" du projet est créé
automatiquement, c'est à dire que vous avez une copie du projet à votre
nom.  Ensuite, pour demander à ce que vos changements soient pris en compte
par le projet d'origine, il faut faire une "pull request" (une demande pour
"tirer" les changements).

Bertrand

---

From: Remy CLAVERIE <[email-masked]>
Date: Sun, 25 Nov 2012 17:01:42 +0100 (CET)

> Message du 25/11/12 16:09
> De : "Bertrand Bordage" 
> A : "Remy CLAVERIE" 
> Copie à : "Jean-Jacques Gerbaud" , "lilypond-user-fr" 

Le 25 novembre 2012 12:47, Remy CLAVERIE  a écrit :

Pour le point 2, c'est le principe à la base de github et bitbucket.  Il n'y a même pas besoin de demander à l'auteur d'un projet pour faire des modifications.  Si on souhaite en faire, un "fork" du projet est créé automatiquement, c'est à dire que vous avez une copie du projet à votre nom.  Ensuite, pour demander à ce que vos changements soient pris en compte par le projet d'origine, il faut faire une "pull request" (une demande pour "tirer" les changements).
 
** Certes, mais je ne parle pas de cela. Il s'agissait d'information facilement accéssible : Comment savoir qui fait qui fait quoi sur le GIT... **
 
Rémy

Bertrand