#gitfr

Demander à cor et à cri depuis de mois, j'ai mis à jour la présentation le dépôt Git et la présentation en ligne. Il y'a malheureusement des petits soucis d'affichage des images mais un rafraichissement règle en général le problème.

gitfr ne sera jamais descendu plus bas que ce 13 février puisque c'est la belle ville de Montpellier qui aura l'honneur d'une présentation Git ;).

C'est le MontpellierJUG qui organise cette soirée à l'université Montpellier II. Toutes les infos et inscription sur cette page.

La version 1.7.9 est sortie le 27 janvier avec plusieurs évolutions intéressantes :

• Un meilleur support des gros fichiers (Git n'étant pas réputé pour ça).

• La signature des commits, qui fait suite au piratage de la machine qui héberge le dépôt Git du projet Linux de Linus Torvalds.

• L'internationalisation est maintenant activée (honte à moi, toujours pas démarré le projet de traduction en Français).

• La possibilité d'ajouter une description à une branche.

• L'option --no-edit quand on amende un commit.

Je vous laisse comme d'habitude lire le changelog mais je trouve cette version bien excitente ! J'attends la mise à jour sur ma machine pour faire quelques tests.

Le changelog

• gitk updates accumulated since early 2011.

• git-gui updated to 0.16.0.

• git-p4 (in contrib/) updates.

• Git uses gettext to translate its most common interface messages into the user's language if translations are available and the locale is appropriately set. Distributors can drop new PO files in po/ to add new translations.

• The code to handle username/password for HTTP transactions used in "git push" & "git fetch" learned to talk "credential API" to external programs to cache or store them, to allow integration with platform native keychain mechanisms.

• The input prompts in the terminal use our own getpass() replacement when possible. HTTP transactions used to ask for the username without echoing back what was typed, but with this change you will see it as you type.

• The internals of "revert/cherry-pick" have been tweaked to prepare building more generic "sequencer" on top of the implementation that drives them.

• "git rev-parse FETCH_HEAD" after "git fetch" without specifying what to fetch from the command line will now show the commit that would be merged if the command were "git pull".

• "git add" learned to stream large files directly into a packfile instead of writing them into individual loose object files.

• "git checkout -B " is a more intuitive way to spell "git reset --keep ".

• "git checkout" and "git merge" learned "--no-overwrite-ignore" option to tell Git that untracked and ignored files are not expendable.

• "git commit --amend" learned "--no-edit" option to say that the user is amending the tree being recorded, without updating the commit log message.

• "git commit" and "git reset" re-learned the optimization to prime the cache-tree information in the index, which makes it faster to write a tree object out after the index entries are updated.

• "git commit" detects and rejects an attempt to stuff NUL byte in the commit log message.

• "git commit" learned "-S" to GPG-sign the commit; this can be shown with the "--show-signature" option to "git log".

• fsck and prune are relatively lengthy operations that still go silent while making the end-user wait. They learned to give progress output like other slow operations.

• The set of built-in function-header patterns for various languages knows MATLAB.

• "git log --format=''" learned new %g[nNeE] specifiers to show information from the reflog entries when walking the reflog (i.e. with "-g").

• "git pull" can be used to fetch and merge an annotated/signed tag, instead of the tip of a topic branch. The GPG signature from the signed tag is recorded in the resulting merge commit for later auditing.

• "git log" learned "--show-signature" option to show the signed tag that was merged that is embedded in the merge commit. It also can show the signature made on the commit with "git commit -S".

• "git branch --edit-description" can be used to add descriptive text to explain what a topic branch is about.

• "git fmt-merge-msg" learned to take the branch description into account when preparing a merge summary that "git merge" records when merging a local branch.

• "git request-pull" has been updated to convey more information useful for integrators to decide if a topic is worth merging and what is pulled is indeed what the requestor asked to pull, including:

• the tip of the branch being requested to be merged;

• the branch description describing what the topic is about;

• the contents of the annotated tag, when requesting to pull a tag.

• "git pull" learned to notice 'pull.rebase' configuration variable, which serves as a global fallback for setting 'branch..rebase' configuration variable per branch.

• "git tag" learned "--cleanup" option to control how the whitespaces and empty lines in tag message are cleaned up.

• "gitweb" learned to show side-by-side diff.

gitfr ne sera jamais descendu plus bas que ce 13 février puisque c'est la belle ville de Montpellier qui aura l'honneur khof d'une présentation Git.

C'est le MontpellierJUG qui organise cette soirée à l'université Montpellier II. Toutes les infos et inscription sur cette page.

gitfr repart à Lyon pour un combo présentation + atelier sur une journée. Cela se passera le 20 février dans les locaux d'Alptis, 25 cours Albert Thomas, de 14h à 21h (8h de conf, même pas peur !).

Si je vous dis que les inscriptions sont déjà closes, vous me croyez ? Désolé, j'ai raté l'ouverture des inscriptions.

Vous connaissez surement la commande git-diff, puisqu'elle existe sur Hg ou SVN. Mais comme d'habitude, git fourmille de possibilités. Petit tour d'horizon.

Le base

Commençons par le basique. Pour connaître les différences entre votre répertoire de travail et votre index :

$ git diff

Entre l'index et votre dépôt :

$ git diff --staged

Entre le répertoire de travail et le dépôt :

$ git diff HEAD

Note : la notation HEAD se retrouve assez souvent (git-log, git-reset...) quand on parle du dépôt, vu qu'il s'agit du commit courant, c'est à dire notre position sur le graphe (l'index étant le prochain commit).

La commande permet de spécifier des fichiers ou des commits (ces deux possibilités peuvent être combinées) :

$ git diff -- monfichier

$ git diff commit

Si vous voulez connaître la différence entre 2 commits :

$ git diff commit1 commit2

Plus intéressant, si vous voulez savoir ce qui existe dans une branche et pas dans l'autre :

$ git diff commit1...commit2

Cela se lit comme suit : affiche moi ce qui existe entre l'ancêtre commun aux deux commits jusqu'au commit2 qui n'existe pas de l'ancêtre commun au commit1.

Le contexte

Par défaut, Git vous propose un contexte de 3 lignes, c'est à dire qu'il affiche 3 lignes supplémentaires en dessous des changements pour vous donner plus d'indications. Si vous trouvez cela insuffisant, voici 2 techniques possibles :

1. La 1ère est bien sûr d'augmenter le contexte avec l'option -U

$ git diff -U5

Pensez à faire un alias si vous préférez toujours disposer d'un contexte d'une taille différente.

1. Demander à Git la fonction qui contient la modification

$ git diff -W

C'est une nouveauté de la version 1.7.8. Vu le nombre impressionnant de langages il n'est pas sûr que Git se débrouille correctement mais d'après mes premiers tests en Python, cela semble plûtot bien fonctionner.

Ignorer les espaces

Il est désagréable de voir son diff pourri parce qu'un collègue à aussi supprimer des espaces. Vous avez à votre disposition les options -b -w pour ignorer les espaces en fin de lignes ou toutes les espaces.

Algorithme patience

La commande implémente aussi un autre algorithme de détection de changement du nom de Patience. Pour faire très court, cet algo se focalise uniquement sur des lignes à fort contenu, alors que l'algorithme classique travaille sur toutes les lignes. Il y'a des cas ou c'est intéressant de l'essayer (notamment quand le diff classique est complètement perdu).

Note : pour de plus amples explications, veuillez vous référer à cette page ci et à celle la.

Faire des statistiques

Je vous laisse regarder par vous même les options --stat, --numstat, --shortstat, --dirstat et --summary :).

Afficher les différences sur la même ligne

Il est intéressant, par exemple pour de la documentation, d'afficher les modifications sur la même ligne. C'est tout l'intérêt du mode word diff.

$ git diff --word-diff

Ne pas afficher les prefixes

Ne pas afficher les a/ et b/, utilise quand on fait des copier / coller :

$ git diff --no-prefix

Chercher une chaine dans le contenu

Si vous cherchez une chaine particulière dans le contenu d'un commit (cad les lignes qui ont été ajoutées ou supprimées), c'est l'option pickaxe qu'il vous faut :

$ git diff -Srenderer HEAD~10..HEAD

Vous pouvez utiliser une expression rationnelle avec l'option -G.

Note : l'option --pickaxe-all affiche l'ensemble du commit, et pas uniquement les fichiers impactés.

Générer un patch

Le comportement par défaut de Git est de générer un patch :

$ git diff > diff.patch

Et encore plein d'autres options

Comme d'habitude, je vous recommande chaudement de lire le manuel de la commande tellement Git regorge d'options (notamment pour aider au scripting). Je n'ai pas parlé de l'option --check pour vérifier les espaces inutiles, le -M et le -C pour détecter copie et déplacement...

Cela fait maintenant un peu plus d'un an que #gitfr existe (1ere conférence le 24 novembre 2010), il est donc temps de faire un petit point. D'abord quelques chiffres :

• quelques centaines d'heures dépensées
• 13 conférences
• ~800 auditeurs aux conférences
• ~4000 visulisations sur parleys.com
• 86 billets de blog
• plusieurs centaines de fotes d'ortografes
• 6 ateliers
• ~120 participants aux ateliers
• 7 jours de congés utilisés
• 0€ gagné

Alors que l'objectif initial était de faire des ateliers, c'est précisemment l'activité la plus faible. Je vois plusieurs raisons :

• Tout d'abord, participer à un atelier demande à comprendre un minimum Git. Il me semble inutile d'organiser un atelier sans que les participants soient d'abord conviés à la conférence.

• Une conférence permet de faire venir des dizaines ou centaines de personnes, l'atelier est lui difficile à faire à plus de 30.

• Un atelier est bien plus compliqué a organiser.

• On m'a plus sollicité pour des conférences, tout simplement. Je n'ai plus le temps pour trouver des salles, je m'adapte aux demandes.

De plus, j'avoue qu'après des dizaines d'heures dépensées pour monter une conférence de qualité, ma motivation et mon énergie pour l'atelir avaient diminués. Je dirais même que je redoutais un peu de faire des ateliers, car cela demande bien plus de préparation. Avec 6 ateliers, et malgré une qualité insuffisante à mes yeux sur les premiers, cette peur s'est estompée.

J'avoue aussi que l'activité du blog est assez faible, car je pense trop souvent à faire des billets trop longs. Je vais donc tenter à l'avenir des billets courts, même si cela nécessite de faire plusieurs billets sur le même sujet. Et bien sûr, cela aussi du temps et de l'énergie.

Vous pouvez constater que #gitfr est une activité purement bénévole. Non seulement, je n'ai pas gagné d'argent avec mais j'ai dépensé 7 jours de congés payés pour les déplacements en province. C'est à ce titre que je demande au minimum le remboursement des frais et une gratuité de l'évènement pour le public : je me déplace uniquement si n'importe qui peut venir assister aux conférences et aux ateliers. Que je ne gagne pas d'argent soit, mais je ne suis pas là pour enrichir ou former une société ! #gitfr est et restera une activité bénévole et gratuite, ce n'est pas dans son ADN de proposer des ateliers payants (il faut pour cela se tourner vers des formateurs, je pense d'ailleurs en faire une liste si cela est utile). Ceux qui me connaissent savent parfaitement mon dégout pour les gens qui cachent leurs activités pro sous des soit-disantes activités associatives. La séparation doit être nette et étanche. Si vous souhaitez une conférence ou un atelier Git, n'hésitez donc pas à demander, #gitfr répondra présent si les conditions le permet !

Et pour finir sur une note positive, je crois que la majorité des participants ont appréciés les conférences et comprennent maintenant l'avantage d'utiliser Git (et globalement les DVCS). C'est finalement le seul objectif de #gitfr : montrer aux développeurs et aux managers qu'ils ont tout à gagner à revoir leurs pratiques de gestion de source. Les DVCS ne sont pas l'avenir, ils sont le présent.

Git est hautement configurable, avec des dizaines de variables possibles dans le fichier de configuration, la longueur de l'aide de l'option config donnant d'ailleurs quelques vertiges. Au lieu de faire un (très) long billet sur les différentes possibilités de configuration, je vous propose plutôt des billets courts sur un thème particulier de la configuration.

Pour ce premier billet, je souhaite aborder le comportement de Git lors d'un push. Ce qui ont suivis l'atelier Git à Bordeaux ne seront pas étonnés par ce choix : ayant totalement oublié cette option, je ne comprenais pas que ma machine ne se comporte pas comme ceux des participants à l'atelier (ma crédibilité en tant qu'expert Git en a sérieusement pâti :).

Commençons par lire le manuel sur l'option push.default :

Defines the action git push should take if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line. Possible values are:

• nothing - do not push anything.
• matching - push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default.
• upstream - push the current branch to its upstream branch.
• tracking - deprecated synonym for upstream.
• current - push the current branch to a branch of the same name.

Comme vous pouvez le constater, si aucun refspec n'est fourni (en ligne de commande ou par configuration) le comportement par défaut est de pousser toutes les branches qui existent en local et sur le serveur. Cela veut donc dire que si vous tapez la commande git push, vous allez mettre à jour sur le serveur toutes les branches que vous avez modifié en local, ce qui est rarement souhaitable. Il faudra indiquer le refspec complet git push origin mybranch pour éviter cela.

C'est pour cette raison que je configure Git avec l'option upstream :

$ git config --global push.default upstream

2 avantages immédiats :

• Il ne pousse que la branche courante.
• Il m'oblige à faire un tracking, ce qui est bien utile.

Maintenant, si vous tentez de pousser la branche test avec la commande git push sans tracking préalable, Git vous répond :

fatal: The current branch test has no upstream branch. To push the current branch and set the remote as upstream, use

git push --set-upstream origin test

Suivez le conseil de Git en tapant la commande ci dessus pour suivre votre la branche distante test sur origin avec votre branche locale test. Vous verrez immédiatement un changement sur votre shell avec l'information u=, qui indique que vos deux branches sont synchronisées.

Rappel sur le tracking

Le tracking consiste à associer une branche locale et une branche distante (dite upstream dans la terminologie Git), ce qui informe Git de la branche distante à utiliser lors d'un git pull. Si vous ne comprenez pas pourquoi vous n'êtes pas plus souvent confronté à cette notion de tracking, c'est tout simplement que Git le fait pour vous la plupart du temps :

• Git suit la branche master lors d'un clone.
• Git suit la branche que vous venez de créer si celle ci existe déjà sur le serveur

C'est donc (la plupart du temps) dans le cas ou créer une nouvelle branche en locale sans existance préalable sur le serveur que vous devez explicitement faire cette association.