Sérieux, je suis pas d'accord. Github marche bien quand on est toujours dedans, et qu'on ne bosse qu'avec ça. C'est d'ailleurs le but de la plateforme: enfermer les développeurs à l'intérieur et faire en sorte qu'ils n'en sortent pas.
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?!
Je me suis retrouvé à devoir "forker" le projet (sur le site web seulement), modifier mon .git/config pour ajouter mon remote, pousser mes commits, retourner sur le site, et finalement faire une demande de pull (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?!? En plus si je veux suivre le projet, je me retrouve à devoir gérer 2 remotes depuis mon dépôt local. Note que c'est courant voire normal de gérer plusieurs remotes si t'es un mainteneur d'un gros projet, mais c'est lourd pour un contributeur intermittent (qui envoie un patch tous les 36 du mois) car on peut se retrouver vite à s'emmêler les pinceaux. Avoir des branches locales et se baser sur un seul remote est bien plus facile.
Bien sûr la raison est de te pousser à gérer tout cela dans ton navigateur, sur le site web, puisque leur UI a un workflow adapté à ces logiques incongrues. Mais franchement je préfère de loin gérer le plus de truc possible dans ma console.
Je parle même pas de la sémantique. C'est pas un fork que je veux faire! Je veux juste patcher un projet, pas le forker. C'est d'ailleurs terrible pour les petits projets: 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.
Non, moi si je veux publier un projet, je reste sur tuxfamily ou autre petit hébergeur. Au moins, ils essaient pas de se faire passer pour du réseau social.
Et je dis tout ça, mais j'ai pas mal utilisé Github, quotidiennement et des milliers de commits lorsque je bossais pour une startup qui l'utilisait. Ça marche très bien tant qu'on reste dedans et qu'on s'adapte à leur logique bizarre de fork, y a pas à dire. Mais c'est loin d'être la meilleure logique de contribution.
Sinon pour répondre, moi aussi, c'est pour moi: je veux réparer des logiciels ou avoir des fonctionnalités, je les code. J'ai appris à ne plus me reposer sur et attendre les autres, mais à faire les choses moi-même.
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é à 10.
Sérieux, je suis pas d'accord. Github marche bien quand on est toujours dedans, et qu'on ne bosse qu'avec ça. C'est d'ailleurs le but de la plateforme: enfermer les développeurs à l'intérieur et faire en sorte qu'ils n'en sortent pas.
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?!Je me suis retrouvé à devoir "forker" le projet (sur le site web seulement), modifier mon .git/config pour ajouter mon remote, pousser mes commits, retourner sur le site, et finalement faire une demande de pull (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?!? En plus si je veux suivre le projet, je me retrouve à devoir gérer 2 remotes depuis mon dépôt local. Note que c'est courant voire normal de gérer plusieurs remotes si t'es un mainteneur d'un gros projet, mais c'est lourd pour un contributeur intermittent (qui envoie un patch tous les 36 du mois) car on peut se retrouver vite à s'emmêler les pinceaux. Avoir des branches locales et se baser sur un seul remote est bien plus facile.
Bien sûr la raison est de te pousser à gérer tout cela dans ton navigateur, sur le site web, puisque leur UI a un workflow adapté à ces logiques incongrues. Mais franchement je préfère de loin gérer le plus de truc possible dans ma console.
Je parle même pas de la sémantique. C'est pas un fork que je veux faire! Je veux juste patcher un projet, pas le forker. C'est d'ailleurs terrible pour les petits projets: 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.
Non, moi si je veux publier un projet, je reste sur tuxfamily ou autre petit hébergeur. Au moins, ils essaient pas de se faire passer pour du réseau social.
Et je dis tout ça, mais j'ai pas mal utilisé Github, quotidiennement et des milliers de commits lorsque je bossais pour une startup qui l'utilisait. Ça marche très bien tant qu'on reste dedans et qu'on s'adapte à leur logique bizarre de fork, y a pas à dire. Mais c'est loin d'être la meilleure logique de contribution.
Sinon pour répondre, moi aussi, c'est pour moi: je veux réparer des logiciels ou avoir des fonctionnalités, je les code. J'ai appris à ne plus me reposer sur et attendre les autres, mais à faire les choses moi-même.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]