Fork me on GitHub

Git 1.7.10 publiée

15/04/2012 10:52 PM | categories: release, git | Commentaires

Pas mal de petites changements dans cette version 1.7.10 sortie le 10 avril. Je voulais initialement tester cette version avant de publier l'annonce mais je n'ai pas eu le cou^H^H^Htemps :(. Mais rapidement de ce qu'ai pu voir :

  • gitk a pas mal de petites évolutions.

  • Un éditeur s'ouvre lors d'un git-commit pour pousser les gens à expliquer les changements.

  • On peut cloner qu'un répertoire.

N'hésitez pas comme d'habitude à commenter ce billet si vous voyez des changements intéressants dans votre façon de travailler avec Git.

Le changelog

  • various "gitk" updates.

  • Teams for localizing the messages from the Porcelain layer of commands are starting to form, thanks to Jiang Xin who volunteered to be the localization coordinator. Translated messages for simplified Chinese, Swedish and Portuguese are available.

  • The configuration mechanism learned an "include" facility; an assignment to the include.path pseudo-variable causes the named file to be included in-place when Git looks up configuration variables.

  • A content filter (clean/smudge) used to be just a way to make the recorded contents "more useful", and allowed to fail; a filter can now optionally be marked as "required".

  • Options whose names begin with "--no-" (e.g. the "--no-verify" option of the "git commit" command) can be negated by omitting "no-" from its name, e.g. "git commit --verify".

  • "git am" learned to pass "-b" option to underlying "git mailinfo", so that a bracketed string other than "PATCH" at the beginning can be kept.

  • "git clone" learned "--single-branch" option to limit cloning to a single branch (surprise!); tags that do not point into the history of the branch are not fetched.

  • "git clone" learned to detach the HEAD in the resulting repository when the user specifies a tag with "--branch" (e.g., "--branch=v1.0"). Clone also learned to print the usual "detached HEAD" advice in such a case, similar to "git checkout v1.0".

  • When showing a patch while ignoring whitespace changes, the context lines are taken from the postimage, in order to make it easier to view the output.

  • "git diff --stat" learned to adjust the width of the output on wider terminals, and give more columns to pathnames as needed.

  • "diff-highlight" filter (in contrib/) was updated to produce more aesthetically pleasing output.

  • "fsck" learned "--no-dangling" option to omit dangling object information.

  • "git log -G" and "git log -S" learned to pay attention to the "-i" option. With "-i", "log -G" ignores the case when finding patch hunks that introduce or remove a string that matches the given pattern. Similarly with "-i", "log -S" ignores the case when finding the commit the given block of text appears or disappears from the file.

  • "git merge" in an interactive session learned to spawn the editor by default to let the user edit the auto-generated merge message, to encourage people to explain their merges better. Legacy scripts can export GIT_MERGE_AUTOEDIT=no to retain the historical behavior. Both "git merge" and "git pull" can be given --no-edit from the command line to accept the auto-generated merge message.

  • The advice message given when the user didn't give enough clue on what to merge to "git pull" and "git merge" has been updated to be more concise and easier to understand.

  • "git push" learned the "--prune" option, similar to "git fetch".

  • The whole directory that houses a top-level superproject managed by "git submodule" can be moved to another place.

  • "git symbolic-ref" learned the "--short" option to abbreviate the refname it shows unambiguously.

  • "git tag --list" can be given "--points-at " to limit its output to those that point at the given object.

  • "gitweb" allows intermediate entries in the directory hierarchy that leads to a project to be clicked, which in turn shows the list of projects inside that directory.

  • "gitweb" learned to read various pieces of information for the repositories lazily, instead of reading everything that could be needed (including the ones that are not necessary for a specific task).

  • Project search in "gitweb" shows the substring that matched in the project name and description highlighted.

  • HTTP transport learned to authenticate with a proxy if needed.

  • A new script "diffall" is added to contrib/; it drives an external tool to perform a directory diff of two Git revisions in one go, unlike "difftool" that compares one file at a time.

  • Improved handling of views, labels and branches in "git-p4" (in contrib).

  • "git-p4" (in contrib) suffered from unnecessary merge conflicts when p4 expanded the embedded $RCS$-like keywords; it can be now told to unexpand them.

  • Some "git-svn" updates.

  • "vcs-svn"/"svn-fe" learned to read dumps with svn-deltas and support incremental imports.

  • "git difftool/mergetool" learned to drive DeltaWalker.

  • Unnecessary calls to parse_object() "git upload-pack" makes in response to "git fetch", have been eliminated, to help performance in repositories with excessive number of refs.

  • Recursive call chains in "git index-pack" to deal with long delta chains have been flattened, to reduce the stack footprint.

  • Use of add_extra_ref() API is now gone, to make it possible to cleanly restructure the overall refs API.

  • The command line parser of "git pack-objects" now uses parse-options API.

  • The test suite supports the new "test_pause" helper function.

  • Parallel to the test suite, there is a beginning of performance benchmarking framework.

  • t/Makefile is adjusted to prevent newer versions of GNU make from running tests in seemingly random order.

  • The code to check if a path points at a file beyond a symbolic link has been restructured to be thread-safe.

  • When pruning directories that has become empty during "git prune" and "git prune-packed", call closedir() that iterates over a directory before rmdir() it.

  • Build with NO_PERL_MAKEMAKER was broken and Git::I18N did not work with versions of Perl older than 5.8.3. (merge 5eb660e ab/perl-i18n later to maint).

  • "git tag -s" honored "gpg.program" configuration variable since 1.7.9, but "git tag -v" and "git verify-tag" didn't. (merge a2c2506 az/verify-tag-use-gpg-config later to maint).

  • "configure" script learned to take "--with-sane-tool-path" from the command line to record SANE_TOOL_PATH (used to avoid broken platform tools in /usr/bin) in config.mak.autogen. This may be useful for people on Solaris who have saner tools outside /usr/xpg[46]/bin.

  • zsh port of bash completion script needed another workaround.

  • 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.

    • Lire et poster des commentaires

    Présentation Git le 12/04 à Lausanne

    30/03/2012 09:40 AM | categories: atelier, gitfr | Commentaires

    gitfr sort de France pour diffuser la bonne parole en Suisse, et plus précisemment à Lausanne. C'est organisé par le JUGL, le Java User Group de Lausanne, et la présentation démarre à 18h30 dans les locaux d'Octo.

    Toutes les infos sur le site du JUGL.

    Lire et poster des commentaires

    Mise à jour de la présentation Git

    01/02/2012 12:50 AM | categories: gitfr | Commentaires

    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.

    Lire et poster des commentaires

    Présentation Git le 13/02 à Montpellier

    01/02/2012 12:30 AM | categories: atelier, gitfr | Commentaires

    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.

    Lire et poster des commentaires

    Git 1.7.9 publiée

    28/01/2012 09:13 PM | categories: release, git | Commentaires

    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.

    Lire et poster des commentaires

    Présentation et atelier Git le 20/02 à Lyon

    26/01/2012 09:07 PM | categories: atelier, gitfr | Commentaires

    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.

    Lire et poster des commentaires

    La commande diff

    26/01/2012 03:48 PM | categories: git git-diff | Commentaires

    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...

    Lire et poster des commentaires

    Retour sur un an de gitfr

    10/01/2012 08:54 PM | categories: gitfr | Commentaires

    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.

    Lire et poster des commentaires
    Articles précédents »