developer.jelix.org is not used any more and exists only for
history. Post new tickets on the Github account.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.
developer.jelix.org n'est plus utilisée, et existe uniquement pour son historique. Postez les nouveaux tickets sur le compte github.
Changes between Version 15 and Version 16 of fr/patchs
- Timestamp:
- Sep 17, 2010, 9:45:45 AM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
fr/patchs
v15 v16 76 76 77 77 Vous pouvez répéter qrefresh, qcommit pour améliorer votre patch. 78 79 Il est conseillé également d'inclure directement dans le patch le message qui sera indiqué dans le commit lorsque le patch sera intégré définitivement dans le dépôt officiel. 80 Cela facilitera le travail de celui qui fera cette intégration, si vous n'avez pas les droits sur le dépôt officiel. Pour cela utilisez l'option -m de qrefresh: 81 {{{ 82 hg qrefresh -m "ticket #123: bug fix on bla bla bla" -u "votre nom ou login bitbucket" 83 }}} 84 Les messages de commit [wiki:fr/mercurial doivent respecter un format]. Cela inclus également votre nom. Si vous ne voulez pas avoir à indiquer le nom à chaque fois, mettez le dans la configuration mercurial (fichier hgrc). 85 78 86 Vous pouvez créer plusieurs patch avec qnew. Souvenez vous que les modifications que vous faites sont pour le dernier patch. 79 Si vous voulez changer pour uneancien patch, vous devez utiliser qpop pour supprimer les patchs du haut.87 Si vous voulez faire un changement dans un ancien patch, vous devez utiliser qpop pour supprimer les patchs du haut. 80 88 Pour appliquer à nouveau le patch le plus récent, utilisez qpush. 81 89 … … 113 121 === Vous souhaitez proposer quelques patches pour une grosse modification === 114 122 115 Maintenir une queue de patch peut être fatiguant quand vous travaillez sur une grosse modification (intégrer un nouveau composant par exemple ).123 Maintenir une queue de patch peut être fatiguant quand vous travaillez sur une grosse modification (intégrer un nouveau composant par exemple, qui demande beaucoup de travail, donc de commits). 116 124 La meilleure façon, dans ce cas, est d'avoir sa propre branche, avec ses propres commits, et cette branche sera mergée dans le trunk à la fin. 117 125 118 Bitbucket vous permet de publier un clone d'un dépôt, et commiter d'yles modifications.126 Bitbucket vous permet de publier un clone d'un dépôt, et d'y commiter les modifications. 119 127 Ensuite vous pouvez utiliser la fonction "pull request" de bitbucket pour informer le propriétaire du dépôt '''officiel''', d'intégrer votre commit dans son dépôt. 120 128 121 129 Donc vous pouvez "forker" le dépôt jelix, commiter dans votre clone et demander un pull. 122 Ajouter un commentaire dans le ticket correspondant sur developer.jelix.org pour informer les autres contributeurs que vous avez fai redes modifications.130 Ajouter un commentaire dans le ticket correspondant sur developer.jelix.org pour informer les autres contributeurs que vous avez fait des modifications. 123 131 124 132 Afin d'obtenir un historique compréhensible, essayer de faire des commits clairs. … … 128 136 129 137 130 == proposer le patch ==138 == Proposer le patch == 131 139 132 140 Enregistrez votre fichier patch, soit dans un ticket existant concernant la modification que vous avez effectué, soit dans un nouveau ticket. Vous enregistrez le patch en cliquant sur le bouton "attach file" dans le ticket.