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.
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.
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.
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.
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.
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).
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.
[^] # Re: rebase
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Nouvelles de Git : 2.20.0, Git Merge, etc.. Évalué à 2.
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.
[^] # Re: rebase
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Nouvelles de Git : 2.20.0, Git Merge, etc.. Évalué à 6. Dernière modification le 10 décembre 2018 à 04:56.
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.
[^] # Re: rebase
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Nouvelles de Git : 2.20.0, Git Merge, etc.. Évalué à 6.
Avant, dans la 2.19.2 et les versions précédentes, il restait plusieurs grosses parties de
git rebase
en Shell: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.
[^] # Re: Un petit contenu accessible aux neu-neux ?
Posté par Christian Couder (site web personnel) . En réponse au journal Presentation "Git Bisect and Testing" au GTAC 2010. Évalué à 3.
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/
[^] # Re: Un petit contenu accessible aux neu-neux ?
Posté par Christian Couder (site web personnel) . En réponse au journal Presentation "Git Bisect and Testing" au GTAC 2010. Évalué à 3.
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.
[^] # Re: KISS
Posté par Christian Couder (site web personnel) . En réponse au journal Présentation sur "git bisect" au Linux Kongress 2009. Évalué à 1.
Il y a déjà eu plusieurs personnes qui ont demandé un mode inversé dans lequel et 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é.
[^] # Re: KISS
Posté par Christian Couder (site web personnel) . En réponse au journal Présentation sur "git bisect" au Linux Kongress 2009. Évalué à 4.
- la problématique des régressions et certains moyens pour les résoudre
- les sous commandes de 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 ( et )
- 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 .
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 (sans arguments). Les autres commandes sont de la (plumbing) qui est surtout destinée à être utilisée par des scripts ou pour du debug ou des utilisations spéciales.
[^] # Re: petite remarque concernant les liens
Posté par Christian Couder (site web personnel) . En réponse au journal Présentation sur "git bisect" au Linux Kongress 2009. Évalué à 3.
[^] # Re: Durée
Posté par Christian Couder (site web personnel) . En réponse au journal Présentation sur "git bisect" au Linux Kongress 2009. Évalué à 2.
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.
[^] # Re: Autre temps, autre moeurs...
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Linux en entreprise : deux nouveaux exemples de migration. Évalué à 1.
[^] # Re: Eiffel
Posté par Christian Couder (site web personnel) . En réponse à la dépêche SmallEiffel devient SmartEiffel. Évalué à 3.
> 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é.
[^] # Re: note, juste en passant
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Vivre du logiciel libre : un exemple. Évalué à 10.
que cet outil n'accepte pas de VHDL standard ?
Ca devrait etre moins compliqué que de tout
redevelopper en libre.
# KDevelop le permet déjà
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Borland : du C++ pour Linux embarqué. Évalué à 0.
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 ?
# Association formant les jeunes
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Adhérer c'est important. Évalué à 5.
(<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 ?
[^] # Re: Rions un peu
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Pourquoi Microsoft Windows XP Embedded et pas Linux embedded ?. Évalué à 2.
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.
[^] # Re: Kate et KDevelop 2.0
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Sortie de Kde 2.2. Évalué à 2.
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.
[^] # Re: On ne sera pas les seuls :-)
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Manif contre la taxe Tasca à la Villette. Évalué à 1.
# On ne sera pas les seuls :-)
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Manif contre la taxe Tasca à la Villette. Évalué à 1.
http://www.transfert.net/fr/net_economie/article.cfm?idx_rub=86&(...)
A demain...
[^] # Re: Vachealait.com
Posté par Christian Couder (site web personnel) . En réponse à la dépêche Taxe des supports informatiques. Évalué à 1.