Gitbuster II

Posté par feth le 24 juin 2011 à 15:55. Modéré par baud123. Licence CC By‑SA.

Étiquettes :

juin

2011

« If there’s something strange
In your history
Who you gonna call?
GitBuster! »

Qui ne s’est jamais retrouvé au milieu d’un conflit de merge cataclysmique, à ne plus savoir distinguer ciel et terre ? À moins d’être un utilisateur expérimenté, ce genre de situation a de quoi rebuter et faire passer à côté de toute la richesse de Git.

Gitbuster, développé par Julien Miotte est un frontal graphique à des outils comme « git rebase », « git cherry-pick » et « git filter-branch ». Le projet est parti à l’origine d’un besoin très personnel de l’auteur de faciliter l’utilisation de « git filter-branch », un outil très performant de réécriture des informations de commit. Le développement, guidé par les demandes de fonctionnalités, notamment de chefs de projet, s’est orienté vers d’autres fonctionnalités de Git, comme le rebase et le cherry-pick.


	Gitbuster, développé par Julien Miotte est un frontal graphique à des outils comme `« git rebase »`, `« git cherry-pick »` et `« git filter-branch »`. Le projet est parti à l’origine d’un besoin très personnel de l’auteur de faciliter l’utilisation de `« git filter-branch »`, un outil très performant de réécriture des informations de commit. Le développement, guidé par les demandes de fonctionnalités, notamment de chefs de projet, s’est orienté vers d’autres fonctionnalités de Git, comme le rebase et le cherry-pick.

Gitbuster offre les fonctionnalités suivantes :

cherry-pick par glisser‐déposer d’une branche sur une autre ;
résolution interactive des conflits de merge ;
création d’une branche à partir d’un commit (git checkout 1234567 -b new_branch) ;
modification des métadonnées de n’importe quel commit de l’historique ;
cherry-pick à partir d’un dépôt distant (qu’il soit sur le Web ou dans un autre répertoire) ;
modification automatique des dates de commit d’une plage horaire vers une autre.

Avec Git, un conflit se produit lorsque l’on essaye d’appliquer un commit introduisant un changement à un certain endroit, alors que le commit courant présente un autre changement. Par exemple, j’essaye d’appliquer le patch suivant :

- ernest
+ napoléon

sur un fichier contenant :
text antoine

Ici, le conflit sera assez simple, et une solution probable sera de remplacer antoine par napoléon. Prenons maintenant le conflit suivant :

<<<<<<<<<< HEAD
place = "mall"
print "Let’s go to the", place
====================
if command == "go":
    place = "mall."
    print "Let’s go to the", place
>>>>>>>>>>> [fix] Cosmit (message volontairement élusif)

Comment le résoudre ? La modification à appliquer porte‐t‐elle sur l’ajout du « if command » ou juste sur le « . » à la fin de « mall » ? Ce commit peut en effet venir d’une branche où le développeur travaille en ce moment sur l’ajout d’une fonctionnalité de commande, mais veut uniquement appliquer ce commit, qui ne concerne en fait que le remplacement de « "mall" » par « "mall." ». Si le commit est récent, ou si le message de commit est suffisamment explicite, il y a des chances que le développeur se souvienne de la modification apportée. Mais que se passe‐t‐il si les souvenirs sont plus lointains, ou si le développeur qui merge n’est pas l’auteur de la modification ?

Parfois, les conflits s’étendent à plusieurs fichiers. Pas évident de déterminer la modification qu’on souhaitait apporter et comment fusionner « à la main » l’état actuel du fichier et la modification.

Gitbuster propose, pour la résolution de conflits de merge, une interface de résolution explicite, présentant :

l’état du fichier avant le merge (ou un message indiquant qu’il n’existait pas avant le cherry-pick) ;
le patch sensé être appliqué (mais qui génère un conflit) ;
l’état « non-mergé » du fichier ;
les options de résolution possibles (ajouter le fichier tel quel, ajouter en éditant, supprimer le fichier).

gitbuster solutions

Gitbuster peut aussi être lancé juste après un conflit lors d’un « git rebase -i », il ne présente alors que la fenêtre de résolution pour ce conflit particulier.

special_mode

Le cherry-pick par glisser‐déposer :

drap'n'dropping

En coulisses

Gitbuster est développé notamment grâce à lui‐même, sur GitHub, au moyen de Python, GitPython et PyQt. Il est constitué de deux projets : gfbi-core pour l’accès aux données et gitbuster pour l’interface graphique.

Pour tester / installer

$ mkvirtualenv gitbuster # gitbuster recommande virtualenwrapper
$ pip install gitbuster

L’utilisation d’autres interfaces entre Python et les systèmes de gestion de versions centralisés ou non est à l’étude (citons Dulwich, pygit2 et évidemment Mercurial).

Un mode démo est aussi disponible et permet de lancer Gitbuster dans un virtualenv, sans modifier son système. Pour lancer le mode démo, téléchargez les sources et lancez le script « demo.sh ».

Gitbuster est installable via pip et supporte setuptools, distutils et distutils2.

What’s next?

Pour la suite, Gitbuster est un logiciel libre, et son avenir dépend avant tout du temps disponible de son auteur principal. Il est possible qu’il devienne agnostique par rapport au gestionnaire de version sous‐jacent. Parmi les évolutions prévues :

gérer les fonctionnalités de push et de pull de code ;
pouvoir éditer les paramètres de suivi (branch tracking) ;
mieux gérer les historiques non‐linéaires ;
prendre en compte Mercurial et Subversion ;
empaquetage dans une distribution GNU/Linux près de chez vous ;
« merger » le ciel et la terre, l’eau et le feu.

Encore merci aux relecteurs de la dépêche et aux testeurs qui se reconnaîtront.

Aller plus loin

Gitbuster sur GitHub (778 clics)
Gitbuster sur PyPI (Python package index) (147 clics)
Profil de Julien Miotte sur GitHub (153 clics)

# Métadonnées

Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 juin 2011 à 16:33. Évalué à -2.

modification des métadonnées de n’importe quel commit de l’historique ;

C'est quoi ça, de la modification rétroactive du passé ? Mauvaise idée, ne pas utiliser.
- [^] # Re:Métadonnées
  
  Posté par mr_spoke le 24 juin 2011 à 16:44. Évalué à 6.
  
  C'est quoi ça, de la modification rétroactive du passé ? Mauvaise idée, ne pas utiliser.
  
  Je pense que c'est une fonctionnalité intéressante pour les personnes qui ne souhaitent pas que leur patron puisse savoir qu'un commit sur un logiciel libre a été produit pendant les heures de travail.
  - [^] # Re:Métadonnées
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 juin 2011 à 16:47. Évalué à 2.
    
    Il dit qu'il n'a plus de genou.
  - [^] # Re:Métadonnées
    
    Posté par mikePerdide le 24 juin 2011 à 19:42. Évalué à 10.
    
    C'est effectivement un des cas d'utilisation qui m'a poussé à développer Gitbuster. Un cas très similaire : le développeur en télétravail qui préfère travailler la nuit et dormir le jour. Pour éviter les conflits avec son chef de projet, il peut décaller toutes les heures de commit avant de pousser son travail sur le dépôt distant.
    
    Je vois d'autres cas où la modification de l'historique peut s'avérer intéressante, notamment avant d'envoyer ses commits :
    - corriger les typos dans les messages de commit
    - squasher des commits (prévu dans la roadmap)
    - corriger l'adresse email ou du nom du committer (il m'est déjà arrivé de committer sur des projets libres mon adresse email professionnelle)
    
    Je suis assez partisan de l'idée de pouvoir committer très fréquemment, sur des modifications atomiques, avant de revenir éventuellement sur l'historique pour harmoniser et regrouper les commits ayant des sujets communs.
    
    Un autre cas d'utilisation : un chef de projet m'a récemment contacté pour me demander si Gitbuster était capable de supprimer tous les commits n'ayant pas été faits par un auteur donné. Il souhaitait passer un projet propriétaire en libre.
    
    Enfin, pour revenir sur la notion de passé : Gitbuster n'incite pas à modifier l'historique commun, et affiche les commits en grisé s'ils ont déjà été envoyés.
- [^] # Re: Métadonnées
  
  Posté par zebra3 le 24 juin 2011 à 17:06. Évalué à 7.
  
  Par exemple, un commit réalisé sur une machine avec un problème d'horloge : si l'on connaît le décalage, on peut remettre la bonne heure dans les métadonnées.
  
  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: Métadonnées
  
  Posté par Nicolas Boulay (site web personnel) le 24 juin 2011 à 17:27. Évalué à 2.
  
  Imagines une branche principal et une fonctionnalité développé dans sa branche. Or la fonctionnalité "lag" un peu. rebase permet de remettre à jour la base de code utilisé par la branche, cela facilite énormément le merge ensuite de la base dans le trunk.
  
  "La première sécurité est la liberté"
  - [^] # Re: Métadonnées
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 juin 2011 à 18:03. Évalué à 1.
    
    Hors sujet : je parlais des modifications de méta-données de commit.
    - [^] # Re: Métadonnées
      
      Posté par MrLapinot (site web personnel) le 24 juin 2011 à 18:35. Évalué à 3.
      
      Tu importes depuis un autre dvcs, par exemple darcs. Cela crée des infos inutiles dans tes messages de commit (genre "ignore-this: jqskdqjslkdjqlsd" dans le cas de darcs). Si ton outil de conversion n'a pas fait le nettoyage, git filter-branch est parfaitement adapté.
  - [^] # Re: Métadonnées
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 24 juin 2011 à 18:04. Évalué à 0.
    
    Pour ça, il y a git merge. Dans l'autre sens, de la branche master vers la branche de dev qui a pris du retard. Ça s'appelle rafraîchir une branche.
- [^] # Re: Métadonnées
  
  Posté par mackwic le 24 juin 2011 à 18:17. Évalué à 10.
  
  Essaye de merger une branche feature-MyFeature avec dev alors que ta branche contient un historique "crade" sur un projet sérieux, et tu vas te faire jeter direct !
  
  Il est communément admit qu'il faut "nettoyer son historique" avant de push une branche sur le dépôt béni, la sanction habituelle en cas de non respect de cette règle est bien évidemment la pendaison par les couilles exécutée par le lieutenant en charge de ton groupe. ;-)
  
  Pour ceux qui ne voient pas à quoi peut ressembler un historique crade, pensez à une suite de commit ayant pour message "Fix de machin", (d'autres commits normaux...), "tentative de fix de machin (le même)", (encore...) "raté, nouvelle tentative", puis ensuite s'enchainent les "Fix", "U NOT WORK" et enfin les "LOL", "PLOP", voire ">o_/" au fur et à mesure que le nombre de commit pour un bug récalcitrant augmente.
  
  Evidemment, chaque commit ne fait que quelques lignes d'écart avec le précédent, et évidemment, vous avez besoin de commit pour que votre testeur puisse récupérer les modifications.
  
  Et évidemment, lorsque le bug est enfin fixé, vous êtes tellement heureux que vous mergez la branche sur le champ, tout fier de vous, avec un message de commit conquérant et héroïque... Quelle erreur ! /o\
  - [^] # Re: Métadonnées
    
    Posté par Zenitram (site web personnel) le 25 juin 2011 à 14:55. Évalué à 10.
    
    Pour ceux qui ne voient pas à quoi peut ressembler un historique crade, pensez à une suite de commit ayant pour message "Fix de machin", (d'autres commits normaux...), "tentative de fix de machin (le même)", (encore...) "raté, nouvelle tentative", puis ensuite s'enchainent les "Fix", "U NOT WORK"
    
    Zut, je me suis fais repérer.
- [^] # Re: Métadonnées
  
  Posté par lilian_h le 24 juin 2011 à 18:34. Évalué à -1.
  
  Je suis complètement d'accord !
  Le but de la gestion de conf n'est pas de modifier le passé, c'est de construire sur le passé.
  => Sinon, utilisez un partage Samba ! :-)
  
  Lilian.
  - [^] # Re: Métadonnées
    
    Posté par mackwic le 24 juin 2011 à 19:31. Évalué à 10.
    
    Comme je l'ai dit au dessus, c'est du simple savoir vivre que d'arranger son historique pour qu'il soit lisible par tous et présentable vis à vis d'une personne extérieure.
    
    Arranger ça veut dire passer 16 commits de 2 lignes destinés à corriger rapidement un bug en 1 seul qui résoud le problème. Arranger ça veut dire aussi expliciter le contenu de tel ou tel commit dans le message parce que au moment de commit il était 2h du mat' et vraiment pas l'envie de rédiger ça.
    
    On est pas tous dans le trip 1984 hein. Arranger ça peut tout aussi bien compléter ou rendre plus lisible que censurer. Car censurer dans un projet d'équipe n'a aucun intérêt, c'est contre-productif.
    - [^] # Re: Métadonnées
      
      Posté par lilian_h le 27 juin 2011 à 12:56. Évalué à -4.
      
      Bonjour,
      
      Il ne s'agit pas de censure, ni de savoir-vivre.
      Ce n'est juste pas acceptable de modifier ce qui a été fait "pour s'arranger", ou pour quelconque raison d'ailleurs.
      
      Si on jardine tous à gauche et à droite, n'importe comment, on arrive vite à un beau bordel.
      
      La gestion de conf c'est un art, et ça ne commence pas en refaisant l'histoire.
      
      Lilian.
      - [^] # Re: Métadonnées
        
        Posté par Étienne le 28 juin 2011 à 09:37. Évalué à 5.
        
        Il semblerait que tu n'ai jamais utilisé de DVCS. Le principe du DVCS c'est que tu as ton arbre complet chez toi. Tant que tu n'as rien publié, tu peux organiser tes commits comme tu le veux.
        
        Un bonne pratique comme le dit mackwic c'est de nettoyer son repository avant de le soumettre, pour transformer une longue série de petits commits en un seul commit cohérent. Ou bien inversement pour séparer un gros commit en plusieurs commits plus petits et plus faciles à relire. Une fois que tu as fait ça tu peux publier ton code. Voir par exemple dans le Git Book : http://book.git-scm.com/4_interactive_rebasing.html
        
        Après publication, en revanche, tu ne dois plus modifier ton historique.
        
        Étienne
        
        [^] # Re: Métadonnées
        
        Posté par lilian_h le 28 juin 2011 à 13:13. Évalué à 2.
        
        Je n'ai jamais utilisé de DVCS, c'est surement pour celà que j'ai réagit.
        
        Merci pour l'explication.
        
        Lilian.
- [^] # Re: Métadonnées
  
  Posté par Victor STINNER (site web personnel) le 24 juin 2011 à 23:26. Évalué à 10.
  
  C'est quoi ça, de la modification rétroactive du passé ? Mauvaise idée, ne pas utiliser.
  
  Je dirai que ce n'est une mauvaise idée que pour les commits déjà public. Pour les commits locaux, on peut en faire ce qu'on veut : les fusionner, les diviser, les réorganiser, les éditer, etc. Je fais ça à peu prêt quotidiennement : je profite de la vitesse de Git/Mercurial pour faire des micro-commits, puis je nettoie avant de pousser. D'ailleurs, Mercurial est assez lent pour ce genre d'opération (greffon histedit), alors que c'est super facile et efficace avec git rebase -i.
# kikoolol

Posté par Jiel (site web personnel) le 24 juin 2011 à 19:31. Évalué à 10.

Juste pour savoir, il n'y a que moi que ça horrifie, cet énorme logo rouge et vert dans la nouvelle ?
- [^] # Re: kikoolol
  
  Posté par Jux (site web personnel) le 24 juin 2011 à 19:47. Évalué à 2.
  
  De manière générale, depuis que la nouvelle version de Linuxfr autorise les images partout, c'est devenu un peu le fouilli graphiquement. Est-il possible d'afficher les images réduites par défaut ? De les déplacer en fin d'article avec références (comme Latex ferait) ?
- [^] # Re: kikoolol
  
  Posté par Eric P. le 24 juin 2011 à 19:53. Évalué à 3.
  
  C'est vrai que le logo aurait pu etre 2 a 3 fois plus petit.
  
  Mais je pardonne tout a l'auteur de la depeche qui m'a fait redecouvrir le tube de Robin, "Let's go to the mall":
  http://www.youtube.com/watch?v=GF1b1pf9DRY
  
  Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.
  - [^] # Re: kikoolol
    
    Posté par feth le 25 juin 2011 à 02:03. Évalué à 3.
    
    Tu vas me laver de tout soupçon immédiatement et dénoncer le vrai coupable nommément. Non mais.
    - [^] # Re: kikoolol
      
      Posté par feth le 25 juin 2011 à 02:08. Évalué à 3.
      
      Hm, c'est pas clair. En fait, je suis initiateur de la dépêche, relecteur en première intention et auteur de quelques phrases jolies. Et de la croix verte qui vous plaît tant. Le reste, c'est surtout mike_perdide.
- [^] # Re: kikoolol
  
  Posté par rewind (Mastodon) le 25 juin 2011 à 10:43. Évalué à 7.
  
  Ceux qui utilise la nouvelle feuille de style ne le voient peut-être pas mais en plus, il y a un tableau pour placer l'image à gauche du texte (et ça se voit avec l'ancienne feuille de style) et c'est très moche. La présentation avec des tableaux, ça faisait un sacré moment que j'avais pas vu ça en HTML...
# Et les queues ?

Posté par CrEv (site web personnel) le 28 juin 2011 à 10:29. Évalué à 3.
Quel serait l'avantage d'utiliser Gibuster après coup, pour nettoyer l'historique, par rapport à l'usage de queues, entre autre :
- Stacked Git (stg)
- Mercurial queues (mq)
J'ai un peu utilisé les deux, et je dois avouer que c'est justement très pratique pour avoir un historique propre en permanence (on peu bouger dans la queue, modifier chacun des commits, etc jusqu'au moment de les valider - et encore, tant qu'on a pas fait de push on peut défaire)

Gitbuster a-t-il un intérêt par rapport à stg/mq ou est-ce juste un usage différent (Gitbuster après coup, stg/mq pendant le dev) ?
- [^] # Re: Et les queues ?
  
  Posté par mikePerdide le 29 juin 2011 à 09:57. Évalué à 3.
  
  Gitbuster permet effectivement de la même façon que stg ou mq de réordonner les commits dans l'historique. Cela peut être fait au cours du développement ou après coup.
  
  Une autre façon d'utiliser Gitbuster concerne le cherry-pick d'une branche à l'autre. Par exemple, je travaille sur ma branche feature, et je m'aperçois que certains commits ont vocation à être intégrés immédiatement à master (corrections de bugs par exemple). J'ouvre Gitbuster avec les deux branches en vis-à-vis, et je copie les commits concernés de ma branche feature à ma branche master. Si le cherry-pick échoue pour cause de conflit de merge, Gitbuster propose une interface de résolution avec des informations pour aider à résoudre le conflit : état original du fichier, modifications qui devaient être appliquées par le cherry-pick (mais qui conflictent), état actuel du fichier, solutions à appliquer (ajouter le fichier tel quel, ajouter le fichier en le modifiant, supprimer le fichier).
  
  Gitbuster peut aussi être utilisé pour répondre aux pull request. Le cas d'utilisation est proche de celui du paragraphe précédent, sauf que la branche feature est distante. De la même façon, on pourra mettre les branches en vis-à-vis et intégrer à la branche master les commits proposés.
  
  Pour reprendre l'image d'un des commentaires, Gitbuster permet donc aussi de construire sur le passé, et de suivre certains workflows d'intégration de commits dans une branche.
  - [^] # Re: Et les queues ?
    
    Posté par CrEv (site web personnel) le 29 juin 2011 à 21:15. Évalué à 3.
    
    hum, je vois, merci pour la réponse. En général le cherry pick je le fais à la main, et jusque là pas trop de problème (enfin surtout transplant)
    
    Question bête, existe-t-il un équivalent à Gitbuster pour mercurial ? J'utilise en ce moment quasi exclusivement mercurial, et je n'utilise plus pour le moment mq (juste parce que je code sous eclipse et que bon, mq sous eclipse c'est moins sympa qu'en CLI) et ça m'intéresserait bien de tester un équivalent.
    - [^] # Re: Et les queues ?
      
      Posté par CrEv (site web personnel) le 29 juin 2011 à 21:18. Évalué à 3.
      
      Bon, ok : https://github.com/mike-perdide/gitbuster/issues/29 :-)
      - [^] # Re: Et les queues ?
        
        Posté par mikePerdide le 29 juin 2011 à 21:59. Évalué à 2.
        
        "Il y a un ticket pour ça" (tm)
# Senser → censer

Posté par LupusMic (site web personnel, Mastodon) le 30 juin 2011 à 02:28. Évalué à 1.

Dans la phrase « le patch sensé être appliqué (mais qui génère un conflit) ; ».