city:capitole

Je trouve que c’est un poil exagéré, mais pour les parties qui sont effectivement problématiques, ça fait un bout de temps que je me dis qu’il serait intéressant de conserver le plumbing de git mais de créer une nouvelle couche de porcelaine par-dessus qui soit plus simple à utiliser pour certains cas courants.

A l’origine, Git était censé être utilisé via Cogito - une IHM un peu mieux adaptée à l’H que git brut de décoffrage : ►http://git.or.cz/cogito - mais bizarrement ses développeurs ont fini par conclure que « Git user interface should be sufficiently user friendly »... Je suis dubitatif - la flexibilité combinée à la performance a un coût et le compromis que propose Git est clairement optimisé pour une niche bien étroite.

Ce qu’on a besoin de savoir pour travailler sur un projet sous SVN :

http://steveko.files.wordpress.com/2012/02/subversion-arrows1.png

Ce qu’on a besoin de savoir pour un projet sur #Github :

http://steveko.files.wordpress.com/2012/02/git-arrows31.png

Ça me paraît assez flagrant.

Un des points que j’ai trouvé important, c’est que normalement seul les mainteneurs ont besoin de connaître plus de commandes et faire des choses plus compliqués que le autres. Là dans Git, ça complexifie les choses à savoir pour tous, pour que les mainteneurs aient un peu moins de boulot. Ça facilite les merge pour les admins, mais ça ne facilite pas l’arrivée de contributeurs.

Pour moi qui ne suis pas férue des arcanes de ces machins en utilisant la surcouche d’un logiciel comme Github, Git devient assez agréable à utiliser. Ne serait-ce que pour basculer d’une branche à l’autre sans avoir à faire un checkout de tout un dossier. Evidemment le changement intervient au niveau de l’interface, n’empêche… j’avoue que j’ai abandonné la formation Git proposé à Capitole du libre car essentiellement pour des ingénieurs déjà initiés, dommage, pourtant motivée j’ai trouvée ça trop complexe et je me suis sentie très con, jamais agréable.

@rastapopoulos Très bien, les deux dessins mais il est dommage que le deuxième confonde Git et Github...

Non non, je ne pense pas que l’auteur confonde, mais il part du principe, dès le début de l’article, qu’une grande partie des projets libres actuels sont sur Github. Donc pour y participer il faut connaître Git et Github, du coup. D’où le fait qu’il l’intègre dans ses explications.

Il rajoute une explication à la fin :

The comparison between a Subversion repository with commit access and a Git repository without it isn’t fair True. But that’s been my experience: most SVN repositories I’ve seen have many committers – it works better that way. Git (or at least Github) repositories tend not to: you’re expected to submit pull requests, even after you reach the “trusted” stage.

C’est aussi mon expérience, comme quand on compare SPIP-Zone où tout le monde peut commiter, et les quelques projets SPIP qui sont sur Github où on peut seulement faire des pull request. Du coup finalement cette manière de travailler hiérarchise plus malgré la soi-disant décentralisation.

Comme le dit l’article, ce n’est pas l’architecture en elle-même qui fait ça, mais plutôt comment les gens l’utilisent en ce moment ainsi que les interfaces disponibles actuellement pour l’utiliser de manière humaine.

J’ai bien compris l’évolution vers « plus de collaboration » quand on est passé de SCCS/RCS à CVS puis SVN, mais GIT ne pousse pas franchement au travail collaboratif, pour les raisons données ci-dessus par @rastapopoulos. Doit-on appeler ça une régression ? A-t-on déjà observé de telles régressions (des usages) dans l’évolution du logiciel libre ?

@RastaPopoulos : j’ai déjà vu ce phénomène (un dépôt git officiel où un seul a le droit d’écrire, les autres ne pouvant faire que des pull requests) mais attention, git et GitHub n’imposent pas ce modèle. Sur GitHub, on peut parfaitement avoir un dépôt où plusieurs personnes peuvent écrire (c’est ce qu’on fait au boulot, cf. ►https://github.com/AFNIC/DNSwitness)

Ben oui, c’est que je dis depuis le début (et ce que dit l’article), c’est pas l’architecture qui impose ça forcément. Mais c’est un usage très fréquent (de plus en plus ? à chiffrer...) dans les projets libres actuellement.

Après on peut extrapoler... :) : il y a peut-être aussi une métaphysique du chacun chez soi avec cette facilité à avoir chacun son petit dépôt. Quand on a un dépôt commun : il faut apprendre à donner des droits d’écriture à plus de monde, et il faut apprendre à travailler en commun, à faire attention au code des autres. Bien sûr que ça limite techniquement, mais peut-être que socialement ça implique plus de chose. Alors que quand on fork tous chacun dans son coin, chacun est un innovateur dans son coin, chacun se vend sur le marché du code source libre, et on intègre les talents : c’est du développement libéral individualiste (ce qui, somme toute, correspond à la philosophie de Linus Torvalds, d’ailleurs).

Bon, là c’est une réflexion pas du tout technique et je pense tout haut en voyant ce que ça donne hein... :)
Mais c’est pas forcément si con.