#gitfr

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.

La version 1.7.8 est sortie le 2 décembre. Comme vous pouvez constater, le changelog est assez gros avec surtout de nouvelles options pour plusieurs commandes et l'habituel lot de corrections.

Le changelog

• Some git-svn, git-gui, git-p4 (in contrib) and msysgit updates.

• Updates to bash completion scripts.

• The build procedure has been taught to take advantage of computed dependency automatically when the complier supports it.

• The date parser now accepts timezone designators that lack minutes part and also has a colon between "hh:mm".

• The contents of the /etc/mailname file, if exists, is used as the default value of the hostname part of the committer/author e-mail.

• "git am" learned how to read from patches generated by Hg.

• "git archive" talking with a remote repository can report errors from the remote side in a more informative way.

• "git branch" learned an explicit --list option to ask for branches listed, optionally with a glob matching pattern to limit its output.

• "git check-attr" learned "--cached" option to look at .gitattributes files from the index, not from the working tree.

• Variants of "git cherry-pick" and "git revert" that take multiple commits learned to "--continue" and "--abort".

• "git daemon" gives more human readble error messages to clients using ERR packets when appropriate.

• Errors at the network layer is logged by "git daemon".

• "git diff" learned "--minimal" option to spend extra cycles to come up with a minimal patch output.

• "git diff" learned "--function-context" option to show the whole function as context that was affected by a change.

• "git difftool" can be told to skip launching the tool for a path by answering 'n' to its prompt.

• "git fetch" learned to honor transfer.fsckobjects configuration to validate the objects that were received from the other end, just like "git receive-pack" (the receiving end of "git push") does.

• "git fetch" makes sure that the set of objects it received from the other end actually completes the history before updating the refs. "git receive-pack" (the receiving end of "git push") learned to do the same.

• "git fetch" learned that fetching/cloning from a regular file on the filesystem is not necessarily a request to unpack a bundle file; the file could be ".git" with "gitdir: " in it.

• "git for-each-ref" learned "%(contents:subject)", "%(contents:body)" and "%(contents:signature)". The last one is useful for signed tags.

• "git grep" used to incorrectly pay attention to .gitignore files scattered in the directory it was working in even when "--no-index" option was used. It no longer does this. The "--exclude-standard" option needs to be given to explicitly activate the ignore mechanism.

• "git grep" learned "--untracked" option, where given patterns are searched in untracked (but not ignored) files as well as tracked files in the working tree, so that matches in new but not yet added files do not get missed.

• The recursive merge backend no longer looks for meaningless existing merges in submodules unless in the outermost merge.

• "git log" and friends learned "--children" option.

• "git ls-remote" learned to respond to "-h"(elp) requests.

• "mediawiki" remote helper can interact with (surprise!) MediaWiki with "git fetch" & "git push".

• "git merge" learned the "--edit" option to allow users to edit the merge commit log message.

• "git rebase -i" can be told to use special purpose editor suitable only for its insn sheet via sequence.editor configuration variable.

• "git send-email" learned to respond to "-h"(elp) requests.

• "git send-email" allows the value given to sendemail.aliasfile to begin with "~/" to refer to the $HOME directory.

• "git send-email" forces use of Authen::SASL::Perl to work around issues between Authen::SASL::Cyrus and AUTH PLAIN/LOGIN.

• "git stash" learned "--include-untracked" option to stash away untracked/ignored cruft from the working tree.

• "git submodule clone" does not leak an error message to the UI level unnecessarily anymore.

• "git submodule update" learned to honor "none" as the value for submodule..update to specify that the named submodule should not be checked out by default.

• When populating a new submodule directory with "git submodule init", the $GIT_DIR metainformation directory for submodules is created inside $GIT_DIR/modules// directory of the superproject and referenced via the gitfile mechanism. This is to make it possible to switch between commits in the superproject that has and does not have the submodule in the tree without re-cloning.

• "gitweb" leaked unescaped control characters from syntax hiliter outputs.

• "gitweb" can be told to give custom string at the end of the HTML HEAD element.

• "gitweb" now has its own manual pages.

• HTTP transport did not use pushurl correctly, and also did not tell what host it is trying to authenticate with when asking for credentials. (merge deba493 jk/http-auth later to maint).

• "git blame" was aborted if started from an uncommitted content and the path had the textconv filter in effect. (merge 8518088 ss/blame-textconv-fake-working-tree later to maint).

• Adding many refs to the local repository in one go (e.g. "git fetch" that fetches many tags) and looking up a ref by name in a repository with too many refs were unnecessarily slow. (merge 17d68a54d jp/get-ref-dir-unsorted later to maint).

• Report from "git commit" on untracked files was confused under core.ignorecase option. (merge 395c7356 jk/name-hash-dirent later to maint).

• "git merge" did not understand ":/" as a way to name a commit.

• "git push" on the receiving end used to call post-receive and post-update hooks for attempted removal of non-existing refs. (merge 160b81ed ph/push-to-delete-nothing later to maint).

• Help text for "git remote set-url" and "git remote set-branches" were misspelled. (merge c49904e fc/remote-seturl-usage-fix later to maint). (merge 656cdf0 jc/remote-setbranches-usage-fix later to maint).

Si vous êtes sur Lille ou sa région et que vous voulez apprendre Git, réservez votre 15 décembre ! Au programme, 3h (voir plus si les participants sont motivés) avec en entrée une présentation de Git, suivi d'un atelier pour débutant.

Je vous avoue que 3h pour une présentation et un atlier est un peu court, mais cela me suffit pour vous donner une idée assez précise des possbilités de l'outil :).

Cet événement est organisé par Ineat Conseil et cela se passera dans leur locaux. Les places sont donc limitées !

L'inscription se fait sur cette page.

Rappel : les participants doivent venir avec Git déjà installé sur leur poste.

Avant dernière conférence de l'année 2011, organisé par l'association alt.netFR. Si vous êtes sur Paris, c'est votre dernière chance de me voir en live avant un bon bout de temps ! C'est Valtech qui accueille cette fois ci dans une grande salle pouvant accueillir plus de 100 personnes.

L'inscription se fait sur cette page.

Pour l'anectode, je suis depuis 16 ans un grand fan d'Unix et du Logiciel Libre et je déteste Windows. je crois que ça va basher plus fort que d'habitude ;).

Un atelier un peu particulier se déroulera le samedi 03 à 15h, et ce pour deux raisons :

• C'est à destination de mes amis de l'AFPy (association Python francophone).
• Les participants sont tous des utilisateurs de DVCS : principalement Hg (étant lui même en Python, c'est le choix du projet CPython et de beaucoup de développeurs Python) et dans une moindre mesure Bzr et Git.

Pour l'anectode, j'avais tanné (et le mot est faible) les mêmes pour abondonner SVN pour Hg[1] il y'a de ça quelques années. Maintenant, je recommence pour passer à Git ;).

L'objectif est triple :

• Montrer à quel point Git déchire sa race :).
• Comparer Git / Hg / Bzr par des praticiens de ces 3 outils.
• Apprendre les évolutions de Hg depuis que je ne l'utilise plus. Et si possible Bzr que je n'ai jamais utilisé.

Pour le déroulement, je vais commencer par ma présentation classique mais sans les sections sur SVN (ils sont tous convaincus, inutile d'en parler) : la notion de workflows des DVCS puis théorie de Git et les commandes qui déchirent. Puis atelier Git.

Je risque d'être un peu malmené cette fois ci, les participants étant loin d'être des novices :). Mais l'ambiance bonne enfant (on se connait tous pour la plupart depuis des années) et les compétences de chacun rendra l'atelier je suis sûr fort intéressant.

Je tente de faire un compte rendu juste après.

[1] Pour être exact, pour passer aux DVCS en général. A l'époque, j'étais sur Hg mais je n'avais pas vraiment de préférence marquée pour l'un des trois. Ce qui n'est plus le cas depuis que je connais Git.

Petit retour qui intéressera peut être les personnes qui souhaitent aussi faire des ateliers Git. Je ne suis pas très satisfait de mon 2eme atelier plusieurs raisons :

1. C'était mon 1er atelier qui ne suit pas directement la conférence. Je ne connaissais donc pas le niveau des participants. Moralité, j'ai rabaché ma prés, au lieu de considérer qu'elle était acquise.

2. Conséquence du point précédent, les participants ont passés plus de temps à m'écouter qu'a travailler sur leurs machines. Il faut donc que je m'oblige à me taire et attendre que les participants essayent les commandes.

3. Je pense qu'il est bon de faire les démos avec un dépôt réel dés qu'on arrive à la partie «cas d'utilisation».

Pour le dernier point, je suis partagé sur la solution à adopter :

• Créer un dépôt spécial pour l'atelier, avec du contenu texte par exemple.

• Partager un dépôt de code que je possède.

• Demander aux participants de venir avec leur code.

Vous en pensez quoi ?

Nouvelle étape du tour de France avec la bonne ville de Bordeaux, pour un combo présentation et atelier sur 2 jours :

• Présentation le 24/11
• Atelier le 25/11

MAJ : Vous pouvez vous inscrire à la soirée sur site du BordeauxJUG, organisateur de l'événement.

Si vous avez déjà travaillé avec un dépôt distant, vous savez comment se comporte Git : il vous indique les références du dépôt distant en ajoutant l'espace de nom origin (dans le cas d'un clone) ou le nom que vous lui donnez si vous l'avez ajouter avec la commande git-remote add. Mais pourquoi Git a t'il ce comportement ?

La réponse se trouve dans le refspec, nom un peu barbare, qui pourrait se traduire en bon français par : «comment je gère les dépôts distants chef ?». Soit ce refspec est spécifié en ligne de commande au moment de l'action (fetch ou push), soit elle se trouve dans le fichier de configuration du dépôt.

Petit rappel

Il est impossible de modifer directement un dépôt distant, vous devez obligatoirement modifier le dépôt local puis pousser vos commits sur le dépôt distant. Autrement dit, modifier un dépôt consiste à synchroniser les bases de données.

C'est là que le refspec rentre en jeu, il permet de définir les branches concernées au moment de la synchronisation.

Clonage

Si vous joué rarement avec le refspec, c'est que vous travaillé la plupart du temps sur un dépôt local que vous avez créé avec la commande git-clone. Ce dernier génère un refspec générique suffisant. Editez le fichier .git/config et vous verrez ces lignes :

[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = /path/to/repos

Une explication rapide : le dépôt distant qui se trouve à l'url spécifié s'appelle en local origin et on associe à chaque référence de branche du dépôt distant une référence de branche locale préfixée par origin.

Mais un deuxième rappel avant d'aller plus loin.

Structure des références

La gestion des références est d'une simplicité affligeante. Tout est contenu dans le répertoire .git/refs. Un répertoire étant un espace de nom, un fichier une référence. Pour fonctionner, Git à besoin de 2 espaces de nom bien particulier :

• heads pour stocker les références locales de type branche.

• tags pour stocker les références locales de type tag.

Vous ne faites pas attention à ces répertoires en temps normal car les commandes Git savent pertinamment que les références sont à ces endroits précis.

Explication

Si je vous dis qu'un refspec s'écrit toujours source:destination, la ligne suivante ne doit pas vous poser trop de soucis. Examinons la de plus prêt :

fetch = +refs/heads/:refs/remotes/origin/

• Le mot clé fetch indique que c'est lu à chaque utilisation de cette commande Le sens de transfert est du dépôt distant (la source) vers le dépôt local (la destination).

• Le symbole + signifie qu'on autorise les récuparation non fast-forword.

• le reste de la ligne est assez explicite. Pour toutes les références se trouvant dans le chemin refs/heads/ dans le dépôt distant, on associe une référence dans le chemin refs/remotes/origin/ dans le dépot local.

Si par exemple le dépôt distant a 3 branches qui se nomment riri, fifi et loulou, vous aurez donc en local 3 branches origin/riri, origin/fifi et origin/loulou.

Importance du refspec

Il est important de maitriser le refspec car tout part de là, c'est en fonction des références à récupérer ou à pousser que Git détermine les objets à synchroniser. Si je demande à récupérer toutes les références distantes, je demande implicitement tous les objets accessibles par ces références, donc toute la base. Au contraire, si le refspec implique des références précises, seuls les objets nécessaires à ces références seront impactés.

Ajout d'un dépôt distant

La commande git-remote permet de manipuler les dépôts distants, avec notamment la commande git-remote add pour en ajouter. Ce dernier se comporte comme la commande git-clone, en configurant le refspec au plus large (toutes les références donc).

refspec en ligne de commande

Le refspec se manipule aussi en ligne de commande, ce qui permet de passer outre la configuration ou d'utiliser Git sans configuration préalable.

Quelques exemples :

git fetch origin +pu:tmp

Récupére la référence pu et les objets associés et appeles la tmp en local.

git push HEAD:master

Pousse la branche actuelle sur la branche distante master.

git push origin master:refs/heads/qa/experimental

Pousse la branche master sur la branche distante expérimental. Nous utilisons ici le nom complet de la référence.

Le refspec :

Refspec particulier qui indique de mettre à jour toutes les branches distantes existantes qui ont un nom identique aux branches locales. C'est en fait le refspec utilisé par défaut au push quand nous en spécifions pas.

Effacer une référence distante

Autre cas particulier. Si vous souhaitez par exemple effacer la référence distante test si vous souhaitez effacer une référence distante, il faut taper :

git push :test

Autrement dit, je pousse une référence vide sur la référence test.

Associer branche locale / branche distante

Comme nous l'avons vu, le refspec en ligne de commande permet d'associer temporairement une branche locale et une branche sur le dépôt distant. Mais comment associer ces deux branches dans la configuration et éviter ainsi de le répêter à chaque fois ? Tout se situe encore dans le fichier .git/config du dépôt local :

[branch "master"]                                                                                   
remote = origin                                                                             
merge = refs/heads/master

Qui veut dire : associe la branche master du dépôt origin à ma référence locale master. Et oh surprise, la ligne est utilisée pour la commande merge, ce qui est tout à faire logique. la commande git-fetch ne fait que récupérer les objets et associer des références. Si vous voulez mélanger votre travail avec le travail distant, il faut donc faire un merge.

Petite remarque, c'est uniquement quand vous avez spécifiée une branche distante (upstream dans le vocabulaire Git) que votre shell vous indiquera si vous avez des commits en avance ou en retard (logique non ?). Cela arrive quand vous avez créé une nouvelle branche locale mais sans l'avoir poussée sur le dépôt distant.

pull = fetch + merge

Vous devez maintenant comprendre pourquoi on dit que la commande git-pull n'est en fait qu'un raccouri pour :

1. git-fetch
2. git-merge origin/master

A quoi sert le fetch ?

La commande git-pull est une commodité car c'est dans 90% des cas ce que l'on souhaite faire. Mais le merge est seulement une des nombreuses possibilités que vous offre Git. La beauté du travail collaboratif avec Git est que cette branche distante est en fait une branche locale (c'est uniquement la référence qui est distante), et que vous pouvez donc faire ce que vous souhaitez avec, comme cherrypicker des commits, faire un rebase... ou un merge. C'est à vous de voir ce qui vous intéresse. C'est la raison pour laquelle des personnes disent sur le Net de ne pas faire que des fetch.

Notez qu'il existe l'option --rebase pour rebaser automatiquement votre branche locale sur la branche distante (ce qui est la aussi un scénario de base).

Conclusion

Je pense avoir fait le tour. Comme d'habitude je vous conseille de de lire les pages du manuel (git-clone, git-fetch, git-push et git-pull).