Matthieu Moy a écrit 3251 commentaires

out of date in transaction », sans l'ombre d'une suggestion de comment sortir de la situation,

Grosse mauvaise foi détectée.
J'ai moi aussi l'occasion d'enseigner git à « quelques » novices et même si je
n'ai certainement pas tes compétences sur les entrailles du bousin, n'étant pas
contributeur sur le projet, je trouve quand même ta remarque assez décalée
lorsqu’il faut expliquer pourquoi on se prend un "push rejected: non-fast-forward".

Avec SVN :

Sending        foo.txt
svn: E155011: Commit failed (details follow):
svn: E155011: File '/tmp/checkout/foo.txt' is out of date
svn: E160028: File '/foo.txt' is out of date

Avec Git :

To /tmp/git
 ! [rejected]        master -> master (fetch first)
error: failed to push some refs to '/tmp/git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

Désolé, je suis sincère quand je dis que je trouve le second plus facile à comprendre. Après, avec les débutants mon plus gros problème est que le message de Git est plus long donc les étudiants s'arrêtent au milieu (et l'incitation à lire la doc est vue comme limite injurieuse !), mais bon …

Mais la façon propre est chiante. Et à la moindre erreur tu peux tout casser.

Mon expérience est exactement l'inverse. J'ai enseigné SVN à des débutants, ils galéraient tous sur des conneries (beaucoup ont été résolues depuis, mais par exemple un svn update était capable de mettre à jour la moitié d'un arbre de travail, s'arrêter sur une erreur du style ! nom-de-fichier.txt et s'arrêter là en laissant tout en vrac, et bon courage pour comprendre ce que ! veut dire), et quand j'essayais de les dépanner ils avaient réussi à mettre une grouille pas possible et je ne pouvais rien faire d'autre qu'un nouveau checkout.

Avec le passage à Git, j'ai beaucoup moins de questions, et infiniment moins d'étudiants qui jettent l'éponge en me disant « monsieur, Git est cassé ». Et quand je dois dépanner quelqu'un qui a mis le bronx dans son dépôt Git, au moins, je sais comment faire : git status dit des trucs pertinents, l'historique est historisé et il y a plein de gardes fous dans Git qui ne sont pas dans SVN pour éviter de perdre des données.

On est loin de l'outil idéal, mais face à des débutants complets qui ne connaissent pas SVN, ça ne se passe pas si mal que ça.

Après, que Git soit très pénible à pendre en main quand on a ses habitudes sous SVN, je crois que personne ne le conteste.

[alias]
svncommit = !git commit -a && git push

Ben non. ton svn commit ne marche pas si ton origin a avancé, il faut un rebase > avant.

Tout pareil qu'avec SVN, non ? Quand ton checkout n'est pas à jour, il faut faire un update (la dernière fois que j'ai essayé SVN le message d'erreur était « out of date in transaction », sans l'ombre d'une suggestion de comment sortir de la situation, qui fait un peu rire jaune pour un outil orienté convivialité et simplicité d'ailleurs).

Mais bon, l'intérêt de Git est quand même de pouvoir commiter plusieurs fois avant de faire un push justement. Et clairement l'interface en ligne de commande de Git est optimisée pour ça.

svncheckout = !git stash && git pull && git stash apply && git stash clear

Ou git pull --rebase --autostash. Ou alors on configure les variables qui vont bien et ça s'appelle juste git pull.

Je n'ai pas eu de temps à consacrer à la préparation du sondage (donc dur de critiquer), mais je suis partiellement d'accord avec toi : le sondage est très orienté « que faites-vous avec Git ? » (qui est super important pour les développeurs) mais très peu sur les difficultés d'apprentissages (qui le seraient aussi).

Ceci dit, il ne faut pas en conclure qu'il n'y a pas d'effort pour rendre le logiciel plus facile à prendre en main. Si tu regardes l'évolution de l'outil, il y a des tas de petites choses qui ont été changées pour aider les débutants, et ça continue. Je donne des cours sur Git à des débutants complets, et les points sur lesquels j'avais toujours les mêmes questions il y a quelques années ont à peu près tous été réglés (ça n'est pas une coïncidence, en général c'est moi qui ai envoyé les patchs ;-) ). Y'a encore du boulot, mais ça avance.

Emacs fait aussi ça assez bien : M-x ansi-term RET ou M-x shell RET pour avoir un terminal, découpage de l'écran via C-x 2 / C-x 3 / …, et possibilité de se connecter à distance à un emacs existant (ssh machine-distante.example.com 'emacsclient -t' par exemple).

Première chose : évites absolument le WebDAV. C'est un hack intéressant quand tu ne peux pas héberger de CGI (rien de spécifique à Git sur le serveur, juste un serveur webdav et ça suffit), mais c'est beaucoup plus lent que git-http-backend et c'est aussi plus buggé (lent => peu d'utilisateurs => peu de volontaires pour corriger les bugs).

Et pour git-http-backend, il faut utiliser deux AliasMatch et un ScriptAliasMatch et se baser sur une détection immonde du paramètre git-receive-pack dans QUERY_STRING ou REQUEST_URI…

Si tu veux héberger un dépôt Git utilisable par un client git et du gitweb utilisable par un navigateur web sur la même URL, tu vas bien être obligé de dire quelque part « ça, c'est pour git-http-backend et ça c'est pour gitweb ».

Sans oublier un git config http.receivepack true sur tous les dépôts…
Tout ça pour juste autoriser l'accès en lecture seule…

Si tu dois positionner la même variable sur tous les dépôts, utilises ~/.gitconfig ou /etc/gitconfig.

Je ne peux que te conseiller de suivre à la lettre la doc de git-http-backend et de rapporter les éventuels bugs sur la mailing-list (mais si c'est juste pour râler que c'est trop dur sans poser de vraie question, tu auras peu de chance d'avoir de l'aide …).

Il n'y a pas de tab à 4 espaces, mais une indentation de l'ensemble du message de commit par 4 espaces dans l'affichage fait par git log (ce qui a toujours été le cas).

On parle bien d'une fonctionnalité codée par Torvalds, là, hein ;-).

C'est toi qui a mis en face les deux phrases que tu cites, mais le « euh non » n'était à mon avis pas en réponse à « le mainteneur officiel » …

Je connais bien la communauté Git, merci (cherches mon nom dans les logs si tu n'es pas convaincu).

Le fait que GitHub soit un gros contributeur de Git est évident. Mais la communauté Git reste une communauté décentralisée, chacun y apporte ce qu'il veut. GitHub apporte beaucoup de code, l'hébergement de git-scm.com, et Junio Hamano y pousse son code régulièrement (mais le dépôt https://github.com/git/git/ n'a rien de plus officiel que git://git.kernel.org/pub/scm/git/git.git/). Si tu cherches une définition de « Git » en temps qu'entité légale, ce qui s'en approcherait le plus serait la Software Freedom Conservancy qui héberge le compte en banque.

L'annonce la plus officielle des releases est faite par Junio Hamano, en publiant les releases notes relues et commentées par la communauté. Le blog de GitHub est un complément très appréciable, mais c'est une initiative unilatérale de GitHub, avec un texte sous leur contrôle et leur propriété.

Ça a l'air d'un détail, mais ce genre de confusion entretient une confusion bien plus embêtante entre Git et GitHub, par exemple on a chaque année des candidats en Google Summer of Code qui candidatent dans l'organisation Git et disant qu'ils veulent contribuer à GitHub, ou des gens qui postent sur la mailing-list de Git en posant des questions spécifiques à GitHub.

Le lien que tu donnes n'est pas vraiment l'annonce officielle. C'est un article sur le blog de GitHub (très bien écrit par ailleurs), et même s'il y a un lien évident entre Git et GitHub, ça reste important de ne pas confondre les deux. Un article sur Git sur le blog de GitHub n'est pas plus officiel que n'importe quel article sur Git sur n'importe quel blog.

Sinon :

La possibilité de faire de l'ASCII-art avec git describe

Ça me parait être un raccourcis un peu étrange. git describe donne maintenant une description meilleure d'un commit, et git log ne casse plus l'ascii-art qui utilise des tabs (ce qui n'est pas du tout inutile, c'était une vraie demande de Linus qui en avait marre de voir les jolis messages de commits bien alignés utilisant des tabs cassés par le préfixe à 4 espace de git log), mais ce sont deux fonctionnalités différentes .

Autant je suis tatillon sur ma vie privée, mon parcours professionnel est, pour moi, une donnée complètement publique.

LinkedIn connaît aussi des choses pas publiques du tout, par exemple : avec qui tu es connecté (pas un secret d'état, mais quand même), quels profils et offres d'emploi tu as consulté (donc indirectement : est-ce que tu cherches à quitter ton emploi actuel, est-ce que tu cherches à recruter), …

Les sous c'est une chose, mais pour que ça soit intéressant il faut aussi avoir des gens intéressés pour bosser à plein temps sur le projet, pas forcément bien payé et avec peu de visibilité sur l'avenir. Avec 30000$ par an, ça fait un salaire assez maigre (en coût total employeur).

Si des devs de Gimp veulent se faire payer pour passer plus de temps dessus, je leur donnerais volontiers un peu de sous, mais s'ils préfèrent garder ça comme loisir, on ne peut pas leur en vouloir.

L'historique immuable avec Git, c'est deux lignes dans un fichier de config (receive.denyNonFastForwards et receive.denydeletes). Si c'est tout ce qui te retient avec Subversion … ;-).

Maintenant, je rejoins Zenitram : si tu veux des contributeurs, donnes leur des bonnes conditions de travail, donc exit Subversion. Contribuer à un projet quand on n'a pas la possibilité de faire un commit, c'est vraiment pas pratique.

Et surtout : le fait qu'un service soit associatif te protège effectivement assez bien des dérives à la sourceforge, mais pas du tout de la faillite ou des interruptions de services à rallonges. On se souvient de kernel.org qui a été coupé très longtemps (je crois que le wiki a mis plus d'un an à revenir), plus récemment, l'hébergeur Olympe mettra la clé sous la porte s'ils ne trouvent pas 28000 € dans les 12 jours qui viennent. Le fait que GitHub ait un service payant et fasse autant de pognon avec est quand même une bonne garantie que ce genre de chose n'arrive pas.

Il y a des tas de bonnes raisons de ne pas choisir GitHub, mais « j'ai plus confiance dans la pérennité d'un service non-commercial » ne me parait pas être la meilleure.

CVS aussi permettait d'avoir l'ensemble des modifs d'un commit.

Justement non. En gros, un cvs commit sur tout un projet est équivalent à for f in $(find . -type f); do cvs commit $f; done. En terme de format de stockage, l'historique de chaque fichier est stocké dans un fichier (.v), mais il n'y a rien qui relie l'historique de tous ces fichiers. Chaque fichier a un ensemble de numéros de versions, mais la version 42 d'un fichier ne correspond pas à la version 42 d'un autre.

Regarde ce que sont obligés de faire des outils comme cvsps (et son option --fuzz) pour voir l'étendue des dégâts.

Une des conséquences est celle que tu donnes sur les accès concurrents, mais ça n'est pas la seule.

les déjà nombreux DVCS libres encore maintenus comme […] Bazaar (2005)

Il y a eu une cinquantaine de commits sur les 4 dernières années (cf. aussi openhub) de développement de Bazaar. « Maintenu » est un bien grand mot, c'est un projet essentiellement à l'abandon.

Quelques explications supplémentaires :

https://news.ycombinator.com/item?id=11667494 (les commentaires de Larry McVoy sont fait avec le pseudo luckydude).
https://lwn.net/Articles/686896/

Un point clé est « Git/Github has all the market share. Trying to compete with that just proved to be too hard. » (Git/Github a toutes les parts de marché. Essayer de concurrencer ça est trop dur).

Ils gardent espoir de trouver un business model, mais ça ressemble un peu à une mise en open-source en guise d'enterrement :-(.

Je suis d'accord que « prix libre » est différent de « gratuit mais dons possibles ». Par exemple, le « Humble Indie Bundle » (http://linuxfr.org/news/humble-indie-bundle-5-jeux-pour-le-prix-que-vous-voulez) avait un modèle intéressant : prix libre, mais strictement supérieur à 0. Et honnêtement, une fois qu'on a mis son numéro de carte bleu dans le système de paiement, on se sentirait vraiment radin de choisir la somme 0.01 €. En pratique, le prix moyen était autour de 10 €.

Linus et tous les contributeurs majeurs de git

Ahem, rien que ça, ça en dit long sur à quel point tu ne t'es pas renseigné sur la question. Ça fait belle lurette que Linus a passé la main sur Git, il ne suit même plus régulièrement la mailing list, il envoie un patch de temps en temps mais je peux t'assurer que le fait que Linus compile Git sous Windows ne changerait strictement rien à la santé de Git pour Windows.

Et c'est pas prêt de changer

Euh, c'est pas comme si il n'y avait personne qui travaillait là dessus … Y'a eu du gros développement pour le support de Git sous Visual Studio (avec contributions de Microsoft à libgit2 en open-source). Maintenant il y a un salarié Microsoft à plein temps sur « Git for Windows ».

Vu que les comptes google sont apparus avant gmail, je vois mal comment ça aurait été obligatoire à une époque d'avoir un compte gmail pour avoir un compte google …

C'est juste que les utilisateurs confondent (et que Google ne fait pas grand chose pour éviter la confusion).

Il y a déjà eu une tentative qui ressemble à ça :

http://linuxfr.org/news/apr%C3%A8s-x-voici-y

Le moins qu'on puisse dire, c'est que ça n'a pas l'air très vivant ;-).

il est possible de comparer différents clichés avec la touche "Z" qui affiche très rapidement en plein écran la photo sélectionnée.

On peut aussi afficher l'image en plein écran sans "Z": il suffit de régler le zoom (par exemple Control-molette) pour n'afficher qu'une image. Et éventuellement d'appuyer un coup sur Tabulation pour supprimer les barres latérales.

Le manuel traduit est maintenant disponible ici :

https://github.com/darktable-org/darktable/releases/download/release-2.0.0/darktable-usermanual-fr.pdf

(si un modérateur passe par là, ça serait cool de l'ajouter aux liens dans la dépêche)

Et un grand merci à toi pour tes vidéos :-) !