• [^] # Re: Pour ma gueule, et je partage ensuite

    Posté par . En réponse au journal Pourquoi je contribue ?. Évalué à 2. Dernière modification le 31 août 2014 à 10:31.

    Github marche bien quand on est toujours dedans

    Github marche aussi très bien pour les mainteneurs qui décident de mettre en place à côté des canaux plus classiques type mailing-list. Github marche bien aussi quand on est pas toujours dedans.

    Que certains mainteneurs décident de se passer de ces canaux plus classique n’est pas la faute de github mais bien plus la supériorité du workflow github du point de vue des-dits mainteneurs. Et que ce soit github ou autre (oui, je reconnais parfaitement que certains mainteneurs préfèrent d’autres workflows que github :)), ç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.

    J'ai essayé l'autre jour de patcher des bugs dans un projet hébergé par github. Au début, je fais un rapport de bug, me disant que je vais y uploader mon patch (correctement formaté avec git format-patch origin/master). Ah pas possible. On peut seulement uploader des images. Sérieux?!

    Gist est fait pour ce genre de choses.

    (on peut même pas faire une demande par commits, mais pour tous les commits d'une branche donné. Uh?!). Sérieux, on trouve ça plus simple?!?

    Ben... oui.

    Dans le workflow git (git en général, pas github) conseillé par 99% des gens (statistiques Bullshit©), les patchs sont supposés se faire dans des branches à part, et les merge se faire en mergant des branches, pas des patchs individuels à coup de cherry-pick. Et c’est pas pour faire joli :
    - c’est vachement plus simple pour rebase (rebase sur master c’est une très très mauvaise idée)
    - c’est vachement plus simple pour gérer les dépendances entre fonctionnalités
    - c’est vachement plus simple pour git log branch1..branch2

    combien de fois (des dizaines!) je me suis retrouvé sur un projet github à me demander s'il s'agit de l'upstream ou non. Pour des petits projets, un moteur de recherche peut répondre plusieurs pages github et la première n'est régulièrement pas l'upstream.

    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 :)