ça me paraît normal que ce sot le mainteneur qui définisse le workflow qu’il préfère — après tout c’est lui qui a à gérer des patchs tous les jours.
Ça je suis d'accord. Je ne me suis d'ailleurs jamais plaint à un mainteneur d'un projet sur github directement, et je suis le processus demandé douloureusement mais silencieusement. Je répondais juste à la remarque générale comme quoi tu trouvais ce nouveau workflow git (car non ce n'est pas le workflow prévu pour git, j'y reviens plus bas) révolutionnaire.
Gist est fait pour ce genre de choses.
Tututut. Demandons par exemple au développeur originel de git, Linus Torvalds: https://github.com/torvalds/linux/pull/17#issuecomment-5654674
Donc non clairement, ce n'est pas le workflow prévu par git.
Ensuite il y a des logiques de workflow différentes, et chacun est libre, encore une fois. Je n'arrive pas avec mes gros sabots voir un mainteneur d'un projet et lui dire que son workflow pue et qu'il devrait changer. Mais lire que git est fait pour ce workflow, ben non clairement. Là faut pas abuser, surtout quand l'auteur de git a déjà dit maintes fois que c'est pas le cas et refuse tout "pull request" passant par le système complètement cassé de github.
Comme dit juste au dessus, c'est pas vrai. Cette façon de faire est une spécificité github. Mais effectivement quand on reste dans la "communauté" github de gens qui ne connaissent que cette façon de faire, on a l'impression que tout le monde aime cela. Ben moi en dehors de cette communauté, je rencontre aussi plein de gens qui n'aiment pas.
Je fais des branches à part pour à peu près tout (je suis un grand partisan d'un workflow par "branche de fonctionnalité"), mais il y a plein de cas pour lesquels ne pas avoir 2 branches séparées est valable, ne serait-ce que pour 2 patchs mineurs sans aucun rapport, et sur des fichiers totalement différents (ils ne peuvent pas interférer). En gros faut quand même distinguer une branche de fonctionnalité d'un bug fix de quelques lignes.
Ensuite, dans mon précédent message, je parlais pas de cherry-pick (j'ai pas compris pourquoi tu m'en parlais). On ne fait pas de cherry-pick tout le temps, effectivement ce serait très lourd. Non on git am (on peut le git apply d'abord s'il s'agit d'un patch compliqué et qu'on veut le tester en profondeur sans avoir peur de le pousser par erreur) un patch proprement formatté par github, avec message, auteur et tout. On teste, puis on pousse.
Pour des petits contributeurs, il est normal de faire les choses par fichiers. Rends toi compte que le système à la github est en train de pousser les gens à mettre en ligne un dépôt public, pour des fois un patch d'une ligne, et qu'ils ne reviendront jamais sur ce dépôt? C'est le marteau pour écraser la mouche. Github simplifie cela en rendant cette partie facile, mais la contrepartie c'est qu'on se retrouve à avoir des dizaines de clones publiées pour plein de projets (les fameux "forks") qui sont juste des zombies laissés à l'abandon.
Donc non le coup de merger des branches, c'est bien entre contributeurs importants, ceux pour qui effectivement cela devient plus pratique d'avoir une branche publique. Tu penses que combien de personnes ont leur propre branche sur les projets énormes comme linux? Les divers mainteneurs, et quelques contributeurs très prolifiques. Et encore souvent, eux se feront des branches sur un même dépôt, pas leur propre dépôt!
Et tu penses que faire son propre dépôt devrait être la norme, même pour les contributeurs mineurs? C'est de la folie. C'est pas pour rien que git send-email a été inventé. C'est parce que contribuer par patch est la norme des petits contributeurs, les branches publiques, on les laisse aux gros contributeurs.
Encore une fois, de la littérature par l'auteur de git: https://www.kernel.org/doc/Documentation/SubmittingPatches
Comme tu le vois, les pull requests sont un seul point, le dernier, pour envoyer des patchs (point 16 de la section 1). Tout le reste se concentre sur le formattage de patch en fichier à envoyer par email (note que lu comme ça, ça a l'air compliqué, mais je pense que c'est parce que c'est un vieux texte. De nos jours, quasi tout ce blabla se fait en une ligne: git format-patch origin/master, "master" à remplacer par une autre branche selon la branche qui sert réellement d'origine). Parce que franchement faire un dépôt public pour un patch, c'est vraiment en faire un peu trop.
Je pense que github a même cet effet pervers d'empêcher les gens à apprendre à connaître vraiment git et son fonctionnement. On rencontre régulièrement des gens qui veulent qu'on fasse tout sur github, mais c'est uniquement parce qu'il ne connaissent que cela et qu'ils se rendent compte qu'il ne savent pas utiliser git en dehors des boutons du navigateur (sérieusement, le fait que tu me répondes "cherry-pick" à un "format-patch" par exemple me fait des doutes quant à ta compréhension de comment marchent les patchs formattés par git; le fait que tu me parles de "branches" alors que github fait même carrêment des clones de partout aussi).
c’est vachement plus simple pour rebase (rebase sur master c’est une très très mauvaise idée)
Oulaaaaah! C'est une très mauvaise idée... sur toutes les branches publiques! Encore une fois, il y a plusieurs logiques. Certains vont effectivement rebaser des branches de fonctionnalités, même publiques (il y a effectivement 2 écoles majeures: les rebaseurs fous, et les mergeurs fous. Curieusement tu m'as l'air d'être un mix des deux...). Mais c'est loin de faire l'unanimité. Encore une fois, tu dis ça à Linus, il t'insultera allégrement. Sa logique, qui est le workflow du projet du noyau linux, et donc probablement très répandue, est de ne jamais rebaser une branche de fonctionnalité publique. C'est exactement la même chose que master, dont tu parlais plus bas. Une branche publique, quelle qu'elle soit, se retrouve copiée dans les dépôts locaux de tous ceux qui ont cloné le dépôt. Et il est tout à fait possible que quelqu'un ait commencé à bosser dessus. Rebaser dans ce cas fout le bordel (oblige de créer une série de patchs et/ou stasher pour ce qui n'est pas déjà sous la forme de commits, supprimer sa branche locale, la recréer, et ré-appliquer tous ses propres patchs. Très lourd). En outre tu casses un historique de hash de commit, ce qui peut créer des problèmes de discussions. À partir du moment où une branche a été rendue publique, on a pu discuter certains commits sur une mailing-list/chat/tracker/etc. Et on rend tout nommage de commit inutile si on se permet de renommer (par rebase) à tout va.
Heu... tu vas sur https://github.com/joincamp/flp.mobi/ par exemple, et juste en dessous du nom tu as « forked from fmap/flp.mobi ». Tu vas sur https://github.com/joincamp/flp.mobi/network/members et tu as le graphe des forks, avec l’upstream en tant que racine de l’arbre. Le seul truc un peu mal fait c’est que c’est pas clair du tout pour un mainteneur de dire « je passe la maintenance à x » (je sais même pas si c’est possible autrement que par un README en fait). Mais c’est pas tellement dramatique dans la mesure ou tu peux autoriser celui à qui tu passes le lead à push dans ton dépot :)
Mouais je comprendrais jamais comment on peut trouver sain cette nouvelle mode de tout forker. Comme tu le confirmes, rien n'est clair. Et je suis désolé, même le "forked from" est loin d'être la première chose que tu vois en arrivant sur la page (encore une fois, pour ceux qui passent leur temps dans github, c'est peut-être évident, mais pour les autres...).
Avec ton exemple, je suis en effet totalement dans le flou. Y a une vingtaine de forks, la plupart quasi les mêmes, mais parfois avec une petite différence, rarement mais parfois avec beaucoup de différences. Et ironiquement, le dépôt original a été vidé (et le README ne passe pas la maintenance justement). Donc si t'es un dév, ou un utilisateur, tu fais quoi? Tu testes les 21 forks un à un pour voir ce qui a changé?
Franchement ce système de fork, c'est plus du réseau social qu'autre chose (plein de gens me forkent! Oh oui allez y, forkez moi! ;-p), mais je trouve cela anti-productif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Pour ma gueule, et je partage ensuite
Posté par Jehan (site web personnel, Mastodon) . En réponse au journal Pourquoi je contribue ?. Évalué à 9.
Ça je suis d'accord. Je ne me suis d'ailleurs jamais plaint à un mainteneur d'un projet sur github directement, et je suis le processus demandé douloureusement mais silencieusement. Je répondais juste à la remarque générale comme quoi tu trouvais ce nouveau workflow git (car non ce n'est pas le workflow prévu pour git, j'y reviens plus bas) révolutionnaire.
Tututut. Demandons par exemple au développeur originel de git, Linus Torvalds: https://github.com/torvalds/linux/pull/17#issuecomment-5654674
Donc non clairement, ce n'est pas le workflow prévu par git.
Ensuite il y a des logiques de workflow différentes, et chacun est libre, encore une fois. Je n'arrive pas avec mes gros sabots voir un mainteneur d'un projet et lui dire que son workflow pue et qu'il devrait changer. Mais lire que git est fait pour ce workflow, ben non clairement. Là faut pas abuser, surtout quand l'auteur de git a déjà dit maintes fois que c'est pas le cas et refuse tout "pull request" passant par le système complètement cassé de github.
Comme dit juste au dessus, c'est pas vrai. Cette façon de faire est une spécificité github. Mais effectivement quand on reste dans la "communauté" github de gens qui ne connaissent que cette façon de faire, on a l'impression que tout le monde aime cela. Ben moi en dehors de cette communauté, je rencontre aussi plein de gens qui n'aiment pas.
Je fais des branches à part pour à peu près tout (je suis un grand partisan d'un workflow par "branche de fonctionnalité"), mais il y a plein de cas pour lesquels ne pas avoir 2 branches séparées est valable, ne serait-ce que pour 2 patchs mineurs sans aucun rapport, et sur des fichiers totalement différents (ils ne peuvent pas interférer). En gros faut quand même distinguer une branche de fonctionnalité d'un bug fix de quelques lignes.
Ensuite, dans mon précédent message, je parlais pas de cherry-pick (j'ai pas compris pourquoi tu m'en parlais). On ne fait pas de cherry-pick tout le temps, effectivement ce serait très lourd. Non on
git am(on peut legit applyd'abord s'il s'agit d'un patch compliqué et qu'on veut le tester en profondeur sans avoir peur de le pousser par erreur) un patch proprement formatté par github, avec message, auteur et tout. On teste, puis on pousse.Pour des petits contributeurs, il est normal de faire les choses par fichiers. Rends toi compte que le système à la github est en train de pousser les gens à mettre en ligne un dépôt public, pour des fois un patch d'une ligne, et qu'ils ne reviendront jamais sur ce dépôt? C'est le marteau pour écraser la mouche. Github simplifie cela en rendant cette partie facile, mais la contrepartie c'est qu'on se retrouve à avoir des dizaines de clones publiées pour plein de projets (les fameux "forks") qui sont juste des zombies laissés à l'abandon.
Donc non le coup de merger des branches, c'est bien entre contributeurs importants, ceux pour qui effectivement cela devient plus pratique d'avoir une branche publique. Tu penses que combien de personnes ont leur propre branche sur les projets énormes comme linux? Les divers mainteneurs, et quelques contributeurs très prolifiques. Et encore souvent, eux se feront des branches sur un même dépôt, pas leur propre dépôt!
Et tu penses que faire son propre dépôt devrait être la norme, même pour les contributeurs mineurs? C'est de la folie. C'est pas pour rien que
git send-emaila été inventé. C'est parce que contribuer par patch est la norme des petits contributeurs, les branches publiques, on les laisse aux gros contributeurs.Encore une fois, de la littérature par l'auteur de git: https://www.kernel.org/doc/Documentation/SubmittingPatches
Comme tu le vois, les pull requests sont un seul point, le dernier, pour envoyer des patchs (point 16 de la section 1). Tout le reste se concentre sur le formattage de patch en fichier à envoyer par email (note que lu comme ça, ça a l'air compliqué, mais je pense que c'est parce que c'est un vieux texte. De nos jours, quasi tout ce blabla se fait en une ligne:
git format-patch origin/master, "master" à remplacer par une autre branche selon la branche qui sert réellement d'origine). Parce que franchement faire un dépôt public pour un patch, c'est vraiment en faire un peu trop.Je pense que github a même cet effet pervers d'empêcher les gens à apprendre à connaître vraiment git et son fonctionnement. On rencontre régulièrement des gens qui veulent qu'on fasse tout sur github, mais c'est uniquement parce qu'il ne connaissent que cela et qu'ils se rendent compte qu'il ne savent pas utiliser git en dehors des boutons du navigateur (sérieusement, le fait que tu me répondes "cherry-pick" à un "format-patch" par exemple me fait des doutes quant à ta compréhension de comment marchent les patchs formattés par git; le fait que tu me parles de "branches" alors que github fait même carrêment des clones de partout aussi).
Oulaaaaah! C'est une très mauvaise idée... sur toutes les branches publiques! Encore une fois, il y a plusieurs logiques. Certains vont effectivement rebaser des branches de fonctionnalités, même publiques (il y a effectivement 2 écoles majeures: les rebaseurs fous, et les mergeurs fous. Curieusement tu m'as l'air d'être un mix des deux...). Mais c'est loin de faire l'unanimité. Encore une fois, tu dis ça à Linus, il t'insultera allégrement. Sa logique, qui est le workflow du projet du noyau linux, et donc probablement très répandue, est de ne jamais rebaser une branche de fonctionnalité publique. C'est exactement la même chose que master, dont tu parlais plus bas. Une branche publique, quelle qu'elle soit, se retrouve copiée dans les dépôts locaux de tous ceux qui ont cloné le dépôt. Et il est tout à fait possible que quelqu'un ait commencé à bosser dessus. Rebaser dans ce cas fout le bordel (oblige de créer une série de patchs et/ou stasher pour ce qui n'est pas déjà sous la forme de commits, supprimer sa branche locale, la recréer, et ré-appliquer tous ses propres patchs. Très lourd). En outre tu casses un historique de hash de commit, ce qui peut créer des problèmes de discussions. À partir du moment où une branche a été rendue publique, on a pu discuter certains commits sur une mailing-list/chat/tracker/etc. Et on rend tout nommage de commit inutile si on se permet de renommer (par rebase) à tout va.
Alors bien sûr, master est la pire, puisque c'est la branche principale où les chances que quelqu'un ait déjà commencé à bosser à partir de là est la plus forte, mais les autres branches publiques sont aussi en danger.
La technique du rebase sur les branches de fonctionnalité publique peut fonctionner "à peu près" pour les projets avec très peu de développeurs, et en particulier où en général une branche de fonctionnalité ne sera éditée que par une seule personne. Dans le cas de github (qui encore une fois, ne fait rien comme les autres), ça passe souvent car non seulement y a qu'un mec qui bosse seul sur la branche, mais surtout il a son propre dépôt avec en général le seul à y avoir les droits d'écriture. Il reste tout de même le problème de l'historique des hashs, mais au moins on ne se marche pas sur les pieds. En gros ils ont réglé le problème du travail collaboratif en le rendant intrinsèquement non-collaboratif. :-/
Et encore une fois, parce que malheureusement tu sors à chaque fois que ce sont les workflows prévus pour git, et donc je crains que tu me croiras pas si je te dis qu'énormément de gens en dehors de github ne veulent pas de cela, je te redonne le workflow de Linus: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
J'aime pas jouer à l'argument d'autorité, mais tu me laisses pas le choix avec tes arguments de "statistiques Bullshit©", qui sont effectivement erronés (et surtout biaisé par le prisme de ceux qui sont beaucoup sur github, je pense). :P
Mouais je comprendrais jamais comment on peut trouver sain cette nouvelle mode de tout forker. Comme tu le confirmes, rien n'est clair. Et je suis désolé, même le "forked from" est loin d'être la première chose que tu vois en arrivant sur la page (encore une fois, pour ceux qui passent leur temps dans github, c'est peut-être évident, mais pour les autres...).
Avec ton exemple, je suis en effet totalement dans le flou. Y a une vingtaine de forks, la plupart quasi les mêmes, mais parfois avec une petite différence, rarement mais parfois avec beaucoup de différences. Et ironiquement, le dépôt original a été vidé (et le README ne passe pas la maintenance justement). Donc si t'es un dév, ou un utilisateur, tu fais quoi? Tu testes les 21 forks un à un pour voir ce qui a changé?
Franchement ce système de fork, c'est plus du réseau social qu'autre chose (plein de gens me forkent! Oh oui allez y, forkez moi! ;-p), mais je trouve cela anti-productif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]