Un client Windows pour Github

[Philippe Bastiani]

Github lance un logiciel client pour Windows
Qui facilite grandement l'utilisation du service sur la plateforme populaire


GitHub est un service web d'hébergement et de gestion de projets logiciels. Il revendique plus de 1 million d'utilisateurs et 2.3 millions de projets Open Source et commerciaux.

Exploiter Github depuis Windows est déjà bien sûr possible... seulement, il fallait disposer d'un des outils suivants:

• un Shell Linux intégrant Git (Cygwin ou MsysGit), ou
• un client Git Windows (TortoiseGit, GitExtensions, ...), ou
• un IDE intégrant Git (Eclipse, Netbeans, IntelliJ, etc). Certains de ces outils proposent d'ailleurs des extensions pour Github;

Mais, certaines opérations Git, comme la génération des clés SSH, ne sont pas simples pour le débutant.

Github, depuis peu, se propose de simplifier l'utilisation de Git sous Windows via son service Web (voir l'annonce ici).

Et lance un nouveau programme compatible XP, Seven, Vista et même Window 8.

L'installateur:

• Se charge de télécharger et d'installer toutes les ressources nécessaires (plateforme DotNet, MsysGit, ...),
• Détecte les paramètres Git et Github (si vous ne disposez pas d'un compte Github, vous serez invité à ouvrir un compte; puis, il vous sera demandé de préciser vos noms et email).
• Analyse vos disques afin de repérer les dépôts Git locaux.
• Se charge de créer une clé SSH.

Après l'installation vous découvrirez une interface au style Metro. Au menu du client, vous pourrez

• Ouvrir dans un explorateur les dépôts Git locaux,
• Ouvrir dans un explorateur Internet les dépôts distants sur Github,
• Accéder à l'historique des commits,
• Modifier les paramètres de connexion à Github,
• Ajouter des dépôts locaux par drag and drop,
• Créer / supprimer des branches de développement,
• Merger les branches,
• Se positionner sur un commit,
• Détecter les fichiers qui ont été modifiés,
• Cloner un dépôt,
• Pousser vos modifications sur le dépôt Github (attention: seul le remote/origin du dépot Github est actuellement accessible).
• Mettre à jour automatiquement le logiciel.

En parallèle du client Windows, une installation du projet Posh-Git est réalisée : Posh-Git propose une intégration de l'outil Git au PowerShell de Microsoft !

Bien qu'en version finale, le logiciel proposé par Github n'est pas stabilisé.
Les points suivants restent à implémenter:

• La gestion des anomalies,
• Le partage des commits (PullRequests),

En résumé : l'outil est épuré et est facile d'utilisation ; mais, il lui manque certaines des fonctionnalités communautaires de Github qui sont, selon moi, l'essence même du service Web.

Les utilisateurs de la plateforme MAC sposent déjà d'un tel outil (plus de détails ici).
Les utilisateurs de la plateforme Linux n'ont pas à disposition un tel outil

Enfin... le client Window peut être téléchargé ici.


Pour rappel, Github c'est :

• Un hébergement, sur un serveur Git, des ressources logicielles,
• Des fonctionnalités communautaires (partage et suivi des projets; suivi de membre Github),
• Un gestionnaire d'anomalies,
• Un Wiki et des pages Web pour chacun des projets,
• Un coin réservé au partage de trucs et astuces (GIST).

L'ensemble de ces services est gratuit pour les projets Open Source. Il est aussi possible d'ouvrir un espace privé sur Github, mais ce service est payant.

[Paul TOTH]

Existe-il des RFC sur Git ?

car franchement je trouve que c'est un cache misère que de faire un programme d'installation qui va se charger d'installer "tout ce qu'il faut" alors que c'est en fait un gros merdier.

Ok, y'a des tas de gens qui trouvent que les DLL c'est génial ça évite le redondance de code...sauf que bien souvent la portion de code utile dans les multiples DLL en question est minime dans le projet, et celui-ci gagnerait énormément à être compilé en statique...à condition d'avoir évidemment des lib bien écrites et un compilateur intelligent qui ne conserve que la partie utile du code.

J'ai cherché le spec de Git mais je ne trouve que les sources, ce n'est pas exactement la même chose.

[Philippe Bastiani]

Envoyé par Paul TOTH

Existe-il des RFC sur Git ?

Je ne pense pas... seules les sources sont IMHO disponibles Il faut donc passer par une glue du type MinGW ou un portage Linux du type Cygwin pour pouvoir faire tourner la version originale de Git... l'ensemble est totalement fonctionnel mais n'est pas très ergonomique sur nos plateformes Windows !

MinGW pèse plus de 80Mo en dll et exe (dont 1Mo pour Git)... au passage, le client Github embarque sa propre installation complète de MsysGit/MinGW ! Mais bon, on à l'habitude

JGit est un portage Java de la bête supporté essentiellement par le plugin EGIT d'Eclipse! Je ne sais pas comment ils font pour valider ce portage...

Quoi qu'il en soit, ce client Github s'installe sans connaissance particulière de Linux et Git: il te génère ta clé SSH et te permet de démarrer un hébergement de Github en quelques clics Mais, rien ne vaut la ligne de commande finalement... c'est là, qu'intervient Posh-Git pour les windoziens.

cdlt,
Philippe

[Paul TOTH]

Envoyé par Philippe Bastiani

MinGW pèse plus de 80Mo en dll et exe (dont 1Mo pour Git)... au passage, le client Github embarque sa propre installation complète de MsysGit/MinGW ! Mais bon, on à l'habitude

ce qui est un non-sens en soit

[Philippe Bastiani]

Envoyé par Paul TOTH

ce qui est un non-sens en soit

Ce n'est pas la taille occupée qui pose problème... mais, le risque de conflit lorsque l'on se retrouve avec plusieurs versions d'une même dll (ou d'un même .so sous X) n'est pas négligeable...

Ici, le client GitHub ET les produits tiers ne sont pas installés dans des dossiers sous ProgramFile... L'installateur utilise le dossier système AppData pour l'installation globale du produit ! Donc à priori, pas de conflit... Cette solution permet aussi de tenir à jour une configuration globale homogène

Envoyé par Philippe Bastiani

Se charge de créer une clé SSH

Le programme se charge biensûr d'installer la clé générée sur le site web de Github

[jmini]

Envoyé par Philippe Bastiani

JGit est un portage Java de la bête supporté essentiellement par le plugin EGIT d'Eclipse! Je ne sais pas comment ils font pour valider ce portage...

JGit est aussi utilisé par Gerrit.

Effectivement il n'est écrit nul part comment la validation est faite...

Pourtant des projets comme GitHub (ou même le support de git pour google-code) n'utilisent pas les outils git directement. Ils ont du en changer certaines partiee (voir peut être même tout) pour l'adapter à leur problématique spécifique d'immense serveur git.

[Firwen]

Ce n'est pas la taille occupée qui pose problème... mais, le risque de conflit lorsque l'on se retrouve avec plusieurs versions d'une même dll (ou d'un même .so sous X) n'est pas négligeable...

Sauf que tout Nix/Nux qui possède un système de package digne de ce nom n'a pas ce problème de versioning des shared library, le src package est compilé avec les libs standard, installées dans un path standard, point final.

Sur Windows par contre, tout le monde sou-poudre joyeusement ses DLL aux 4 coins du système ( Program Files, system32, AppData et j'en passe ), histoire d'etre sur d'avoir 4 versions d'une même bibliothèque et d'emmerder ses voisins.
Espérons que ça change avec le futur "package system" made in Microsoft.

Quand à Git, son problème n'est pas tant ses dépendances directes aux shared library, il n'en a que trés peu.

ldd -r `which git`
linux-vdso.so.1
libz.so.1
libresolv.so.2
libpthread.so.0
libc.so.6

Le problème est qu'il a été conçu et designé pour tourner dans un shell POSIX/NIX, et que le passage sous Win nécessite de reproduire toute la couche *NIX :s

[Aquanum]

Oh ! Git existe sous Windows ?

On est vendredi ! J'ai le droit de troller ! \o/

[Paul TOTH]

Envoyé par Firwen

Sauf que tout Nix/Nux qui possède un système de package digne de ce nom n'a pas ce problème de versioning des shared library, le src package est compilé avec les libs standard, installées dans un path standard, point final.

Sur Windows par contre, tout le monde sou-poudre joyeusement ses DLL aux 4 coins du système ( Program Files, system32, AppData et j'en passe ), histoire d'etre sur d'avoir 4 versions d'une même bibliothèque et d'emmerder ses voisins.
Espérons que ça change avec le futur "package system" made in Microsoft.

Quand à Git, son problème n'est pas tant ses dépendances directes aux shared library, il n'en a que trés peu.

ldd -r `which git`
linux-vdso.so.1
libz.so.1
libresolv.so.2
libpthread.so.0
libc.so.6

Le problème est qu'il a été conçu et designé pour tourner dans un shell POSIX/NIX, et que le passage sous Win nécessite de reproduire toute la couche *NIX :s

c'est pourquoi la documentation du protocole est bien plus importante que le code. Avec une doc bien faite, n'importe quel programmeur avec n'importe quel langage un tant soit peu évolué pour faire un client Git.

c'est comme ça que j'ai fait un client SIP en 600Ko

[dolanor]

Oui en effet, la documentation du protocole est importante, mais git n'avait pas vocation a avoir 20 milliards de clients à la base. A la base, il fallait trouver un remplacant a bitkeeper au moment ou les conflits entre bitkeeper et le monde opensource a fait stopper la licence a titre gratuit que possédait linux pour gérer ses versions. Bref, pas le temps de lancer une tournée d'opinion de savoir comment gérer un nouveau protocole fantastique pour les versions.
Le but ct d'avoir quelque chose permettant de gérer la charge de travail que bitkeeper tenait sur le noyau linux et si possible faire mieux.
Comme ca devait etre rapide et comme c'est aussi un "con" egocentrique ( http://fr.wikipedia.org/wiki/Git#Origine_du_nom ), Linus s'en est chargé lui meme au debut, en decidant quelle fonctionnalité il avait besoin. Un projet guidé par un benevolent dictator, quoi. Et puis bon, Linus n'imagine pas trop l'interet de développer un client pour systeme windows (qu'il doit considérer, comme tout bon "con" égocentrique, un systeme d'un autre age ne méritant que la mort. Pourquoi developper pour ce systeme ?)
Depuis, le projet est maintenu par une autre personne et d'autres développeurs, il a pris du poids dans le monde de la gestion de version (notamment grace a github et ce genre de plateforme). Mais je pense que l'idée de créer une spec de protocole ne leur a pas effleuré l'esprit car ils ne voient pas l'intérêt d'une telle chose actuellement. J'imagine qu'il y'a de quoi ecrire des wrappers pour d'autres langages et que ca leur suffit.

Apres, si tu veux savoir un peu comment ca fonctionne, tu peux lire ca : http://git-scm.com/book/en/Git-Internals . Meme si ca n'est pas une spec, ca explique déjà plus comment git gère son archivage, sa gestion des hashs etc. Mais encore, ce n'est pas une spec.
Mais en même temps, je ne connais pas beaucoup de specifications pour des systemes de gestion de versions. Je ne pense pas qu'il en existe pour SVN, CVS, ClearCase, VSS, Team Foundation Server, mercurial, darcs, fossil ou autre.

[Paul TOTH]

Envoyé par dolanor

Oui en effet, la documentation du protocole est importante, mais git n'avait pas vocation a avoir 20 milliards de clients à la base. A la base, il fallait trouver un remplacant a bitkeeper au moment ou les conflits entre bitkeeper et le monde opensource a fait stopper la licence a titre gratuit que possédait linux pour gérer ses versions. Bref, pas le temps de lancer une tournée d'opinion de savoir comment gérer un nouveau protocole fantastique pour les versions.
Le but ct d'avoir quelque chose permettant de gérer la charge de travail que bitkeeper tenait sur le noyau linux et si possible faire mieux.
Comme ca devait etre rapide et comme c'est aussi un "con" egocentrique ( http://fr.wikipedia.org/wiki/Git#Origine_du_nom ), Linus s'en est chargé lui meme au debut, en decidant quelle fonctionnalité il avait besoin. Un projet guidé par un benevolent dictator, quoi. Et puis bon, Linus n'imagine pas trop l'interet de développer un client pour systeme windows (qu'il doit considérer, comme tout bon "con" égocentrique, un systeme d'un autre age ne méritant que la mort. Pourquoi developper pour ce systeme ?)
Depuis, le projet est maintenu par une autre personne et d'autres développeurs, il a pris du poids dans le monde de la gestion de version (notamment grace a github et ce genre de plateforme). Mais je pense que l'idée de créer une spec de protocole ne leur a pas effleuré l'esprit car ils ne voient pas l'intérêt d'une telle chose actuellement. J'imagine qu'il y'a de quoi ecrire des wrappers pour d'autres langages et que ca leur suffit.

Apres, si tu veux savoir un peu comment ca fonctionne, tu peux lire ca : http://git-scm.com/book/en/Git-Internals . Meme si ca n'est pas une spec, ca explique déjà plus comment git gère son archivage, sa gestion des hashs etc. Mais encore, ce n'est pas une spec.
Mais en même temps, je ne connais pas beaucoup de specifications pour des systemes de gestion de versions. Je ne pense pas qu'il en existe pour SVN, CVS, ClearCase, VSS, Team Foundation Server, mercurial, darcs, fossil ou autre.

je suis bien d'accord sur ton analyse, mais je trouve tout de même cela dommage

Internet ne serait pas ce qu'il est sans les RFC, quand à Linux, c'est le principal reproche que je fais à ce système, il est blindé de HOWTO mais pas un seul WHY...c'est à dire que tu as des tas de procédures à suivre à la lettre quand tu rencontres un problème mais très peu d'explication sur le pourquoi du comment...si tu veux comprendre tu dois plonger dans les sources qui sont souvent un assemblage assez complexe de library toutes aussi hermétiques les unes que les autres.

A ce titre VLC est une belle prouesse dans le genre: comment mettre un tas de codecs qui s'ignorent royalement les uns les autres dans un seul et même client.

[reda_lulu]

je ne pense pas que je suis à la bonne place , ma question est une petit peur hors-sujet ,
mais quelle technologie a été utilisée pour crée cette appli (vu l'interface graphique assez spéciale , retrouvée sur une autre appli ) merci