Christian Couder a écrit 19 commentaires

Je ne sais pas si tu parles de libgit.a qui est créé lors de la compilation de Git, ou si tu parles de libgit2.

libgit2 est un projet différent, qui a été initialement créé à partir du code de Git, mais qui a pas mal divergé depuis. Ce n'est pas sûr qu'ils arrivent bientôt à intégrer ou réimplémenter tout le git rebase.

libgit.a par contre n'est pas très adapté pour être réutilisé dans différents outils.

Effectivement les parties les plus coûteuses en terme de performances, sont celles qui ont été portées le plus tôt historiquement en C. Néanmoins, sous Windows en particulier où le fork/exec est assez coûteux, cela apporte quand même des petits gains de performance de tout porter en C.

Les autres raisons pour lesquelles l'élimination du Shell dans les commandes Git est intéressante sont de faciliter le portage et l'installation de Git sur des systèmes où il n'y a pas forcement de Shell de type sh installé par défaut, et surtout de faciliter la maintenance (amélioration, débogage, re-factorisation, réutilisation, …) du code commun à de nombreuses commandes.

Avant, dans la 2.19.2 et les versions précédentes, il restait plusieurs grosses parties de git rebase en Shell:

1. https://github.com/git/git/blob/v2.19.2/git-rebase.sh
2. https://github.com/git/git/blob/v2.19.2/git-rebase--interactive.sh

Ce sont des étudiants pour le Google Summer of Code 2018 qui ont porté ces scripts en C.

En fait depuis 2008, il y a eu de nombreux efforts par des développeurs et/ou des étudiants pour le Google Summer of Code (notamment en 2008 et 2010) pour en porter une partie, car initialement tout était en Shell.

C'est possible de démarrer un noyau dans une VM ou sur une autre machine, oui.

Par exemple dans cet email, Ingo Molnar décrit brièvement son environnement de test:

http://article.gmane.org/gmane.linux.scsi/36652/

Comme indiqué dans la documentation, git bisect sert à trouver le commit à l'origine d'un bug par une sorte de dichotomie dans le graphe des commits.

Oui effectivement, c'est possible et c'est même utilisé. (C'est sur les slides 47 et 48.)

Il y a déjà eu plusieurs personnes qui ont demandé un mode inversé dans lequel bad et good sont intervertis justement pour cela. Il y a même eu des patchs postés sur la liste, mais ils n'étaient pas complets et donc ça n'a pas été intégré.

La présentation et l'article décrivent pas mal de chose :

- la problématique des régressions et certains moyens pour les résoudre
- les sous commandes de git bisect et comment elles s'utilisent
- les principaux algorithmes et les raisons pour lesquels ils sont utilisés
- les meilleures pratiques
- un peu certaines commandes liées (git rev-list et git replace)
- un peu les évolutions possibles

donc il n'y a pas de miracle, ça prend de la place.

Et c'est destiné principalement à des développeurs avancés, en particulier des développeurs du noyau Linux vu l'audience du Linux-Kongress.

Pour les utilisateurs, il y a la page de manuel de git bisect: http://www.kernel.org/pub/software/scm/git/docs/git-bisect.h(...)

Et il y a aussi l'article que j'ai écrit en février dernier pour LWN.net: http://lwn.net/Articles/317154/

Enfin une petite recherche sur son moteur préféré permet de trouver pas mal de choses, en particulier des utilisateurs qui décrivent leur expérience (le plus souvent très positive) avec la bête.

Concernant le nombre de commandes de Git, pour une utilisation normale voire même avancée, il y a besoin de seulement une vingtaine de commande, ce sont les commandes renvoyées par git help (sans arguments). Les autres commandes sont de la plomberie (plumbing) qui est surtout destinée à être utilisée par des scripts ou pour du debug ou des utilisations spéciales.

Je suis d'accord que ça aurait été mieux. J'essayerai de faire mieux la prochaine fois.

C'était 45 minutes. Et effectivement j'avais beaucoup de pages donc je suis allé très vite sur chaque. (Et oui j'ai réussi à ne pas dépasser les 45 minutes.)

Sinon l'accueil du public a été plutôt bon. En particulier je crois que Dirk Wetter le chairman du program committee du Linux Kongress était très content.

Mais bon le Linux Kongress ce n'est pas énorme comme manifestation. Il y avait en tout une centaine de personnes et la plupart ont décidé d'aller voir la présentation qui était faite en même temps que la mienne ou alors d'aller se balader en ville ou se reposer, car il y avait une vingtaine de personnes environ à ma présentation.

Les investisseurs voulaient certainement que la boîte soit en difficulté pour pouvoir la racheter pas cher.

> > le ramasse-miettes

> Super. Et pour les performances, c'est comment ?

D'abord tu peux compiler tes programmes sans GC et gérer la mémoire toi meme.

Ou alors tu compiles avec le GC et tu utilises les instructions qui le désactivent dans les zones ou les périodes critiques.

Tu peux aussi spécififier certains paramètres pour que par exemple le GC ne se déclanche qu'à partir d'un certain niveau de mémoire utilisé.

Pourquoi ne pas corriger les problèmes qui font
que cet outil n'accepte pas de VHDL standard ?

Ca devrait etre moins compliqué que de tout
redevelopper en libre.

C'est pas pour troller, mais KDevelop 2.1 qui
est en version beta et devrait sortir en meme
temps que KDE 3.0, le permet déjà (grace au
travail de Ralf Nolden).

Bref, pourquoi se focaliser toujours sur Borland
dont les produits sont en retard et ne sont pas
libres, alors qu'il y a déjà au moins une
solution équivalente libre ?

Je cherche une assos qui ferait régulièrement
(<troll>c'est à dire plus régulièrement qu'une
install partie tous les 6 mois</troll>) de la
formation de jeunes aux logiciels libres (et/ou
au développement).

Quelqu'un connait ça en région parisienne ?

Comme il est dit dans la news, la nouvelle version


de KDevelop (version 2.1), qui va sortir en meme


temps que KDE 3.0 Beta1, supporte la


cross-compilation (avec gcc).


Voir http://dot.kde.org/1007435836/(...)">http://dot.kde.org/1007435836/(...(...))">http://dot.kde.org/1007435836/(...(...(...)))





Cette nouvelle version pourra etre utilisée avec


KDE 2.2 ou KDE 3.0.

Il vaut mieux pour les débutants que KDE ait un éditeur dont l'interface soit consistante avec les autres applis KDE.

D'autre part faire un KPart avec vim ou gvim ou emacs ou xemacs utilisable dans Konqueror ou d'autres applis c'est pas simple et ça ne serait pas consistant non plus.

A non je me suis trompé d'un jour, en fait c'est vendredi (aujourd'hui) et non samedi qu'ils manifestent...

Il y a une autre manif demain au même endroit:

http://www.transfert.net/fr/net_economie/article.cfm?idx_rub=86&(...)

A demain...

Tu veux dire l'interview de Tacsa ?