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

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

Bonjour,

bonjour également,

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.

Je ne connais absolument pas git mais sii c'est facile d'accès, avec des règles accessibles, "pourquoi pas" pour moi !

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

Voici la mienne ! :slight_smile:

···

Le 23/11/2012 10:18, Philippe Nenert a écrit :

--
JJG

Linux ? Y a moins bien mais c'est plus cher !

OUI

···

2012/11/23 Jean-Jacques gerbaud <****@****>

Le 23/11/2012 10:18, Philippe Nenert a écrit :

Bonjour,

bonjour également,

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.

Je ne connais absolument pas git mais sii c'est facile d'accès, avec des règles accessibles, "pourquoi pas" pour moi !

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

Voici la mienne ! :slight_smile:

--
JJG

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


liste de diffusion lilypond-user-fr
lilypond-user-fr@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user-fr

--
Benjamin Coudrin
****@****
(+33)6.09.11.00.83

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

···

2012/11/23 Jean-Jacques gerbaud <****@****>

Le 23/11/2012 10:18, Philippe Nenert a écrit :

Bonjour,

bonjour également,

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.

Je ne connais absolument pas git mais sii c'est facile d'accès, avec des règles accessibles, "pourquoi pas" pour moi !

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

Voici la mienne ! :slight_smile:

--
JJG

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


liste de diffusion lilypond-user-fr
lilypond-user-fr@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user-fr

--
Benjamin Coudrin
****@****
(+33)6.09.11.00.83

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.

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

···

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

* Git — Wikipédia

_______________________________________________
liste de diffusion lilypond-user-fr

lilypond-user-fr@

https://lists.gnu.org/mailman/listinfo/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.

OUI

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

Bien cordialement,
~Mike

···

On 23 nov. 2012, at 10:18, Philippe Nenert <****@****> wrote:

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

Pourquoi

···

Le 23 novembre 2012 12:44, ****@**** <****@****> a écrit :

On 23 nov. 2012, at 10:18, Philippe Nenert <****@****> wrote:

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://github.com/horndude77/open-scores

Bien cordialement,
~Mike


liste de diffusion lilypond-user-fr
lilypond-user-fr@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user-fr

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

je ne le connais pas, a voir ...

···

--
Martial

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.

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

Bonjour,

Bonjour Bertrand,

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

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.
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.

...........

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à : > Redirecting…

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

Mais ...maintenant ?

On attend la suite.

···

Le 23/11/2012 18:30, Bertrand Bordage a écrit :

--
JJG

Linux ? Y a moins bien mais c'est plus cher !

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

···

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à : > Git - Book*
C3%A9marrage-rapide-Param%C3%**A9trage-%C3%A0-la-premi%C3%**
A8re-utilisation-de-Git<Git - Book;

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

Mais ...maintenant ?

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

···

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 ?

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 :

  3. On modifie les fichiers qu'on souhaite en essayant d'éviter de faire trop de modifications à la fois (sans quoi la relecture est hardue).

  4. On regarde le "diff" qui indique tous les changements ayant été faits sur des fichiers.

  5. On sélectionne les changements qui vont constituer le "commit" de l'étape suivante (étape facultative si toutes les modifications sont à prendre en compte).

  6. 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".

  7. 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

Hello,

···

Le 25 novembre 2012 12:47, Remy CLAVERIE <****@****> 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

Message du 25/11/12 16:09

···

Le 25 novembre 2012 12:47, Remy CLAVERIE <****@****> 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).

** 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