Au revoir tumblr ! Le nouveau site se trouve à cette adresse : http://gitfr.net/blog
Ce site passe en mode archive à partir de maintenant (plus de nouveau contenu) et sera accessible à l’adresse gitfr.tumblr.com.
Si vous êtes abonné par le flux RSS feedburner, vous n’avez rien à faire.
Junio, le mainteneur de Git, a proposé le 1er avril, de réduire le cycle de développement d’une version stable à 8 semaines. Cette nouvelle approche est effective depuis la sortie de la 1.7.5, ce qui veut dire que la prochaine versions stable, aka la 1.7.6 devrait sortir très prochainement (le 19 juin).
La première semaine aprés la sortie d’une release stable est consacrée en priorité à fixer les bugs de régression.
Cycle d’intégration de nouvelles fonctionnalités à partir de la deuxième semaine, en fusionnant de la branche next vers master, ou de la branche pu vers next.
Semaine N, une version release candidate (rc0) est taggée. Tous les sujets dans next sont triés (pour inclusion dans master ou attente de la prochaine version).
Semaine N+1, une deuxième version rc est taggée. L’objectif est de tester à fond pour trouver d’éventuelles régressions, et plus aucune fonctionnalité nouvelle est acceptée.
Semaine N+2, une troisième rc sort.
Semaine X, la version finale sort.
Vous pouvez constater 2 inconnues, N et X. Idéalement N est la quatrième semaine et X la huitième. Mais pas question pour Junio de respecter à la lettre les dates si un problème survient, c’est une feuille de route indicative, en sortant trois ou quatre rc si nécessaire.
Ce cycle assez court pour un projet aussi important que Git est possible par la gestion des branches :
master, la branche principale de la prochaine stable.
next, la branche de stabilisation de la prochaine stable.
pu, la branche d’intégration de la prochaine stable.
maint, la branche de maintenance de la dernière stable.
Une nouvelle fonctionnalité ne va pas directement dans master, mais passe d’abord par pu, puis next. Si tout donne satisfaction, alors la branche est mergée dans master. Cela signifie que :
vous pouvez utiliser une version stable, en stabilisation ou en cours de développement.
une fonctionnalité est largement testée, analysée et discutée avant d’arriver dans la branche principale.
On retrouve les bonnes pratiques des outils de gestion de source, mise à mal par l’immonde SVN (et ses amis) qui nous ont fait croire que les branches étaient le mal. Mais ca sera le sujet d’un autre billet :).
Vous connaissez surement la commande blame, présent dans tous les outils de gestion de source, et qui permet de connaitre l’auteur de chaque ligne d’un fichier. Dan Gindikin nous gratifie de git-blameall, un petit script en Python (il faut donc qu’un interpréteur Python soit présent sur votre système, ce qui est le cas par défaut sur Linux et MacOS) qui permet d’avoir la mếme information pour toutes les lignes qui ont existées dans l’histoire de ce fichier.
Vous avez donc une colonne supplémentaire qui vous donne le SHA1 ou cette ligne fut effacée. A garder sous le coude !
Voici une copie d’écran :
La quatrième version de la branche 1.7.5.x est sortie le 2 juin, soit seulement 5 jours aprés la précédente. C’est la dernière ligne du changelog qui nous donne la réponse.
The single-key mode of “git add -p” was easily fooled into thinking that it was told to add everthing (‘a’) when up-arrow was pressed by mistake.
Setting a git command that uses custom configuration via “-c var=val” as an alias caused a crash due to a realloc(3) failure.
“git diff -C -C” used to disable the rename detection entirely when there are too many copy candidate paths in the tree; now it falls back to “-C” when doing so would keep the copy candidate paths under the rename detection limit.
“git rerere” did not diagnose a corrupt MERGE_RR file in some cases.
La troisième version de maintenance de la branche 1.7.5.x est sortie le 27 mai.
The bash completion scripts should correctly work using zsh’s bash completion emulation layer now.
Setting $(prefix) in config.mak did not affect where etc/gitconfig file is read from, even though passing it from the command line of $(MAKE) did.
The logic to handle “&” (expand to UNIX username) in GECOS field miscounted the length of the name it formatted.
“git cherry-pick -s resolve” failed to cherry-pick a root commit.
“git diff —word-diff” misbehaved when diff.suppress-blank-empty was in effect.
“git log —stdin path” with an input that has additional pathspec used to corrupt memory.
“git send-pack” (hence “git push”) over smalt-HTTP protocol could deadlock when the client side pack-object died early.
Compressed tarball gitweb generates used to be made with the timestamp of the tarball generation; this was bad because snapshot from the same tree should result in a same tarball.
La deuxième version de maintenance de la branche 1.7.5.x est sortie la 20 mai.
“git add -p” did not work correctly when a hunk is split and then one of them was given to the editor.
“git add -u” did not resolve a conflict where our history deleted and their history modified the same file, and the working tree resolved to keep a file.
“git cvsimport” did not know that CVSNT stores its password file in a location different from the traditional CVS.
“git diff-files” did not show the mode information from the working tree side of an unmerged path correctly.
“git diff -M —cached” used to use unmerged path as a possible rename source candidate, which made no sense.
The option name parser in “git fast-import” used prefix matches for some options where it shouldn’t, and accepted non-existent options, e.g. “—relative-marksmith” or “—forceps”.
“git format-patch” did not quote RFC822 special characters in the email address (e.g From: Junio C. Hamano jch@example.com, not From: “Junio C. Hamano” jch@example.com).
“git format-patch” when run with “—quiet” option used to produce a nonsense result that consists of alternating empty output.
In “git merge”, per-branch branch.
“git merge-one-file” did not honor GIT_WORK_TREE settings when handling a “both sides added, differently” conflict.
“git mergetool” did not handle conflicted submodules gracefully.
“git-p4” (in contrib) used a wrong base image while merge a file that was added on both branches differently.
“git rebase -i -p” failed to preserve the history when there is a redundant merge created with the —no-ff option.
La première version de maintenance de la branche 1.7.5.x est sortie la 5 mai.
When an object “$tree:$path” does not exist, if $path does exist in the subtree of $tree that corresponds to the subdirectory the user is in, git now suggests using “$tree:./$path” in addition to the advice to use the full path from the root of the working tree.
The “—date=relative” output format used to say “X years, 12 months” when it should have said “X+1 years”.
The smart-HTTP transfer was broken in 1.7.5 when the client needs to issue a small POST (which uses content-length) and then a large POST (which uses chunked) back to back.
“git clean” used to fail on an empty directory that is not readable, even though rmdir(2) could remove such a directory. Now we attempt it as the last resort.
The “—dirstat” option of “diff” family of commands used to totally ignore a change that only rearranged lines within a file. Such a change now counts as at least a minimum but non zero change.
The “—dirstat” option of “diff” family of commands used to use the pathname in the original, instead of the pathname in the result, when renames are involved.
“git pack-object” did not take core.bigfilethreashold into account (unlike fast-import); now it does.
“git reflog” ignored options like “—format=..” on the command line.
“git stash apply” used to refuse to work if there was any change in the working tree, even when the change did not overlap with the change the stash recorded.
“git stash apply @{99999}” was not diagnosed as an error, even when you did not have that many stash entries.
An error message from “git send-email” to diagnose a broken SMTP
connection configuration lacked a space between “hello=
“git stash -p —no-keep-index” and “git stash —no-keep-index -p” now mean the same thing.
“git upload-pack” (hence “git push” over git native protocol) had a subtle race condition that could lead to a deadlock.
Le breizhcamp est une journée conférence organisée le 17 juin par plusieurs communautés techniques de Rennes avec des sessions sur Java, Ruby, Android, etc. Je suis présent à cette conférence pour 2 sessions : la keynote, avec pour thème les communautés et une session sur le langage Python.
Étant sur place, j’ai proposé aux organisateurs un atelier sur Git (étonnant non ?). Limité à 40 personnes et organisé la veille (le 16 juin), l’objectif est de prendre par la main les participants, en partant de zéro et les amener à une maîtrise minimale de Git :
Cela signifie que vous devez venir avec votre ordinateur équipé de Git si vous souhaitez participer à l’atelier. Vous pouvez bien sur assister seulement aux présentations ou regarder les autres manipuler.
Pour rappel, les tutoriels pour installer Git :
Je ne vous cache pas que je suis allergique à Windows (que je n’utilise plus personnellement et professionnellement depuis 1999) et que je suis donc beaucoup moins à l’aise sur cette plateforme. De plus, nous manipulerons principalement en ligne de commande et non au travers d’un quelconque IDE.
Suivez ce lien pour les inscriptions.
#gitfr continue sa promotion de Git en allant cette fois ci à Strasbourg, invité par le ElsassJUG, groupe de Javaistes Alascien. La soirée va être riche car je fusionne la présentation DVCS avec la présentation Git, ce qui devrait donner un contenu d’environ 2h. Comme nous avons la salle jusqu’a 22h30, une longue session de question / réponse est possible à la fin de chaque partie.
La soirée est limitée à 90 personnes, dans les locaux d’Alcatel-Lucent à Illkirch.
Pour s’inscrire, suivez ce lien.
A bientôt autour d’une bière Alsacienne ! :).
PS : Je n’avais pas prévu de me déplacer en province avant le Brezhcamp, mais le ElsassJUG avait déjà une soirée DVCS pour le mois de juin.
Si la plupart des gens considèrent GitHub comme une superbe plateforme d’hébergement de code, beaucoup sont encore dubitatifs sur la délégation des tickets (bug et/ou fonctionnalité), et préfèrent utiliser Trac, Redmine ou JIRA. Il est donc intéressant d’apprendre que le projet Ruby on Rails (qui pour l’anecdote, est hébergé depuis le premier jour de GitHub) utilise officiellement GitHub pour ses tickets de bugs.
Le retour d’expérience va donc être très intéressant. Et sans nul doute, les GitHubbers (les développeurs de GitHub) seront très sensibles et réactifs aux remarques et retours, étant eux mêmes des utilisateurs de RoR.
