31 octobre 2013

Git sucks

Titre tapageur - serais-je un peu provocateur ?


Non, je ne vais pas faire l'apologie de Clearcase, je suis très content de Git en tant que développeur et je n'ai absolument pas l'intention de changer, même pour un autre DVCS.

Par contre, je suis mainteneur du plugin Git pour jenkins. J'ai hérité de ce plugin sans trop savoir comment, au départ en backportant des correctifs utilisés par CloudBees puis rapidement faute d'une mainteneur en place. Et j'ai rapidement compris pourquoi : ce plugin est un amalgame de pull-requests en tout genre.

Le problème de la pull-request, c'est


  1. quand on crée un patch, et donc une pull-request, on essaie de faire minimaliste. On ne fait pas un gros refactoring juste pour la beauté du geste. On va donc ajouter un "if (foo) { ... } else" dans le code existant. 25 pull requests plus tard la méthode fait 400 lignes et est incompréhensible.
  2. si c'est un mécanisme de revue de code formidable, en opensource la pull-request a ce désagréable effet de bord de permettre à un contributeur de "balancer" du code par dessus le mur, sans s'impliquer forcément dans le projet. D'où l'absence de continuté sur ce plugin.

Bon, ça c'est l'historique, qui n'aide pas, mais pas le coeur du problème.

L'un des principaux objectifs pour la version 2.0 du plugin Git était d'introduire le support de l'authentification via le plugin credentials.

L'option 1, c'était JGit. Il y a quelques temps le plugin Subversion est passé à svnkit plutôt que de piloter le client svn pour des raisons comparables. JGit prométait de faire de même. Sauf que JGit est encore loin du niveau de maturité nécessaire pour être utilisé dans le plugin jenkins. J'ai rapidement découvert la ... créativité des développeurs dans leur usage de Git, et le manque de documentation de JGit, ainsi que l'absence de fonctionnalités pourtant pas mineures. Quand je pense que les utilisateurs d'Eclipse se basent dessus j'ai un peu peur...

JGit reste donc une option expérimentale, et ça risque d'être le cas encore un bon moment.


L'option 2, c'était de conserver le pilotage de la ligne de commande git. Plusieurs problèmes majeurs, et c'est ce qui me fait dire que "Git - i.e., le client git en ligne de commande - sucks"

  1. le client git n'a pas de mode non-interactif. Il peut donc bloquer en demandant à l'utilisateur son username, ce qui bloque jenkins par la même occasion. Je ne connais pas d'outil en ligne de commande qui n'ai pas une option "batch", "quiet" ou "force", bref un truc prévu justement pour ce genre de cas de figure où il n'y a PAS d'utilisateur en face de la console.
  2. le client git ne fournit AUCUN moyen de passer les paramètres d'authentification. En http il se base éventuellement sur .netrc (un fichier prévu pour ftp soit dit en passant), et en ssh il se base sur le client ssh et vous laisse dans la m... StackOverflow regorge de hacks divers pour contourner ces problèmes, et même la doc officielle s'en lave les mains et vous dit de bricoler un script shell. 
To pass options to the program that you want to list in GIT_SSH you will need to wrap the program and options into a shell script, then set GIT_SSH to refer to the shell script.


Ce qui, bien évidement, ne fonctionne que sur un système Unix-like (JENKINS-20356)


Je cherche toujours l'option 3. Il n'existe à ma connaissance pas d'autre client Git que je pourrais utiliser depuis du code Java (des suggestions ?).


Update:
Certains sont surpris. Après tout JGit est utilisé par EGit, mais aussi Gerrit, ou GitBlit; alors quoi, peut être que le plugin jenkins est juste codé avec les pieds - ce qui n'est pas faux mais bon je m'égare.
Je viens d'apprendre que le plugin git maven lui aussi souffre des limitations de JGit. Entre autre des file leaks sous windows, problème rapporté par de nombreux utilisateurs de git-plugin. 

De mon côté je lorgne sur libgit2, qui permettrait d'utiliser un client git natif. Mais évidemment il n'existe pas de binding Java :'(