Forum Programmation.autre git et merge graphique

Posté par  (site Web personnel) . Licence CC By‑SA.
Étiquettes :
2
19
mar.
2021

Salut,
suite à une réflexion que je me faisais dans un autre post, je me demandais quel outil vous utilisez, sur Windows, pour effectuer vos merge (ou diff) en mode graphique (pas avec le git diff ou git merge), en dehors des IDE (dont je sais que certains font bien le job comme Eclipse, ou VSCode) ?

J'utilise Meld qui fonctionne bien (en particulier pour les diff), mais pour les conflits de merge, WinMerge à l'avantage qu'en ouvrant le fichier en conflit avec WinMerge, depuis l'explorateur de fichiers, on voit les 2 versions côte à côte. Quand avec Meld, il faut passer par la commande git mergetool, car l'ouverture depuis l'explorateur de fichiers fera apparaître les caractères de contrôle (=======).

  • # [HS] Mercurial

    Posté par  . Évalué à 2.

    Vu qu'en arrivant, il n'y avait pas de versionning en place, j'ai pu choisir l'outil qui va bien.
    Donc Mercurial, c'est tout aussi puissant et ça peut s'utiliser via une interface graphique (HgWorkbench). Après comme on a une réputation a tenir, on active la console en bas de l'interface histoire qu'il y ait plein de commandes qui défilent.

    Franchement, mis à part le fait que Git soit leader et dispose donc de forges telles que GitHub et GitLab, je ne vois pas ce qu'il a de mieux. Est-ce que l'un d'entre vous a utilisé les deux et a trouvé la réponse ?
    (c'est une vrai question)

    Les vrais naviguent en -42

    • [^] # Re: [HS] Mercurial

      Posté par  . Évalué à 3.

      Mercurial, c'est tout aussi puissant et ça peut s'utiliser via une interface graphique (HgWorkbench).

      Sous windows, il doit bien y avoir tortoiseGit, me semble?

      Après comme on a une réputation a tenir, on active la console en bas de l'interface histoire qu'il y ait plein de commandes qui défilent.

      Si c'est ça la raison qui te fait utiliser la ligne de commande, j'espère que tu as au moins mis un thème "matrix-like", en vert sur noir.

      je ne vois pas ce qu'il a de mieux

      Ne connaissant pas mercurial, ni dart, ni bazaar, et très, très peu fossil, je ne peux répondre sur «l'aspect métier» (je n'ai vraiment utilisé que SVN, et encore, en étant seul sur le projet, un peu de fossil et git).
      Le seul truc que je peux dire en gros c'est:

      Sur le plan technique à minima (et sur ma debian), git dépend grosso merdo de C et de perl, le paquet lui-même pèse 36.2M. Mercurial, lui, pèse lui-même 923K+13.2M (~14M) et dépend de python, à vue de nez, l'installation totale me consommerait donc ~30.8M, un peu moins que git.
      Pour être franc, ça me surprend énormément, ça a du changer à un moment (git aurait pris de l'embonpoint peut-être? Je vois une chiée de binaire qui sont probablement peu utilisés dans l'archive… bref), parce que c'est l'un des trucs auxquels je fait attention quand je choisis un outil.

      Toujours sur le registre technologique, mercurial est implémenté dans un langage qui n'est lié à aucun standard. À l'heure actuelle, la version proposée dans les dépôts stables de Debian dépends de python2. Qui n'est plus maintenu et est considéré obsolète depuis combien de temps, déjà? (je sais, ce sont 2 dates différentes).

      En gros: git est codé en C, mercurial en python. J'ai personnellement un fort biais envers les langages qui ont un vrai standard, et plusieurs implémentations dont aucune n'est "l'implémentation de référence".

      Ça se discute probablement, mais vu que j'aime l'idée de pouvoir utiliser un logiciel 20 après avec les correctifs et améliorations apportées depuis, ben le fait d'être codé en python est déjà un désavantage monstre.

      Maintenant, je veux bien croire qu'il puisse être supérieur à git, reste à savoir en quoi ça impacte l'utilisateur final?

      Dans le cas, par exemple, de fossil, l'avantage sur git est clair: c'est une forge, pas un simple DVCS. De plus, c'est facile et robuste à migrer: un seul fichier à déplacer.
      Dans le cas de mercurial? Je n'ai jamais vu d'arguments qui me semblent si importants.

      • [^] # Re: [HS] Mercurial

        Posté par  . Évalué à 1.

        Sous windows, il doit bien y avoir tortoiseGit, me semble?

        Je l'avais essayé il y a quelques années, à l'époque ça ne fournissait qu'une interface équivalente à TortoiseSVN, ce qui (pour moi) reste un ensemble de raccourcis pour éviter de taper des commandes. Ça a peut-être changé depuis.

        Le "Workbench" de Mercurial propose directement une vue d'ensemble de l'état d'un dépôt, permet de visualiser les interactions entre les branches, parcourir les différentes révisions, de demander facilement des diffs entre la révision complète ou un simple fichier par rapport à la version locale.
        Donc non, pour moi ce n'est pas comparable.

        Si c'est ça la raison qui te fait utiliser la ligne de commande,

        Au début, j'ai pris l'habitude d'afficher la console pour afficher les messages d'erreurs originaux de mercurial, mais au final, la seule fois que j'ai dû m'en servir a été pour importer un repo SVN (fonction non prévue dans l'interface graphique). En fait, depuis ça ne sert plus qu'à décorer la fenêtre.

        Toujours sur le registre technologique, mercurial est implémenté dans un langage qui n'est lié à aucun standard. À l'heure actuelle, la version proposée dans les dépôts stables de Debian dépends de python2. Qui n'est plus maintenu et est considéré obsolète depuis combien de temps, déjà? (je sais, ce sont 2 dates différentes).
        […]
        Ça se discute probablement, mais vu que j'aime l'idée de pouvoir utiliser un logiciel 20 après avec les correctifs et améliorations apportées depuis, ben le fait d'être codé en python est déjà un désavantage monstre.

        Je n'y avais pas pensé, mais la pérennité est un argument fort.

        Maintenant, je veux bien croire qu'il puisse être supérieur à git, reste à savoir en quoi ça impacte l'utilisateur final?

        Je n'ai pas dit qu'il était foncièrement supérieur à Git, je les considère plutôt à égalité techniquement, avec 109 points de plus pour Mercurial à cause de l'ergonomie du Workbench

        Les vrais naviguent en -42

    • [^] # Re: [HS] Mercurial

      Posté par  (site Web personnel) . Évalué à 2.

      Pour mes projets perso, j'avais choisi Mercurial, et j'étais hébergé sur Bitbucket. Mais Bitbucket a abandonné Mercurial … et il n'y a pas beaucoup d'options pour avoir un hébergement Mercurial, donc je vais les passer sur Git (framagit instance GitLab) : c'est un process en cours.

      Pour le boulot, c'est compliqué de recommander Mercurial plutôt que Git. Ce dernier a clairement gagné la bataille (s'il y a eu bataille) : du coup, recommander Mercurial quand la plupart des devs ne "connaissent" que Git et que beaucoup d'outils s'interfacent avec Git mais pas avec Mercurial, c'est compliqué.

      Sinon, en termes de fonctionnalités, j'avais choisi Mercurial parce que les commandes sont plus simples et en règle plus unitaires (quand dans Git une commande par le jeu d'options peut réaliser des choses assez différentes : e.g. checkout). Mais bon globalement, les 2 sont assez similaires.
      Comme je fais une formation à mes petits camarades au travail sur git, je connais probablement maintenant mieux git que hg ! :-(

      Sinon, peut-être un point positif pour git est peut-être la résolution de conflit de merge où tout se passe dans le fichier à merger, quand dans hg, il faut lancer une commande hg resolve … bon d'un autre côté, on peut voir ça aussi comme un point positif : on indique exactement à hg, ce qui se passe.

      Bref, pour avoir à utiliser les 2, ils sont assez similaires avec leur petites différences. Pour moi, je dirai c'est une question de préférence (comme d'utiliser KDE ou Gnome).
      Mais en environnement pro, je ne peux pas envisager d'autres outils que git (malheureusement).

    • [^] # Re: [HS] Mercurial

      Posté par  . Évalué à 1.

      A l'époque, Mercurial m'a beaucoup aidé dans la transition entre svn et git (ça été très dur).

      Dans mes lointains souvenirs, je ne souviens plus d'un truc, est-ce que tu peux me dire si il y a moyen d'éditer l'historique avec Hg ? Pour moi, c'est la fonctionnalité qui tue de git.

      • [^] # Re: [HS] Mercurial

        Posté par  . Évalué à 2.

        est-ce que tu peux me dire si il y a moyen d'éditer l'historique avec Hg ?

        Oui mais c'est parfois déconseillé.

        On va passer rapidement sur la fonction "rollback/undo" : tant que la dernière révision est "draft" (n'a pas été poussé vers l'extérieur ou tiré par quelqu'un), il est possible d'annuler le dernier commit, ou de le modifier. Il n'y aucun risque de ce côté là. J'imagine que Git propose les mêmes fonctions.

        Par contre, il existe des extensions standards qui permettent de modifier l'historique des commits quelque soit leur état (secret / draft / public).
        Pour l'avoir malencontreusement utilisé sur une révision publique, je ne raconte par le bordel que ça a mis dans la base (les nouveaux hash ne correspondant plus, les ordis ayant déjà récupérés l'ancienne version se retrouvaient avec 2 tête de branches et plus possible de commiter quoique ce soit avant d'avoir ré-appliqué la modification manuellement sur chaque client…).
        Cela dit, sur des révisions locale (secret ou draft), c'est pratique et peu risqué (en tout cas je n'ai jamais eu de soucis). Je me suis encore servi cette semaine de l'extension "strip" pour faire détruire une branche locale.
        De même il m'arrive d'utiliser l'extension "rebase" pour changer l'ordre des commits ou les déplacer d'une branche à une autre.

        Les vrais naviguent en -42

        • [^] # Re: [HS] Mercurial

          Posté par  . Évalué à 2.

          Dans git aussi c'est problématique sur une branche partagée, gitlab protège d'ailleurs la branche master contre cela.

          L’intérêt du truc c'est surtout le travail sur branche où se fait le développement de fonctionnalité et on commit plein de petit changement sans se prendre la tête pour ensuite quand les tests ont été fait, tout compresser dans un seul commit qui sera mergé dans la branche principale. De ce que tu me racontes, ça semble faisable.

          • [^] # Re: [HS] Mercurial

            Posté par  . Évalué à 1.

            Pour le coup je n'ai jamais essayé de fusionner des commits.

            Les vrais naviguent en -42

        • [^] # Re: [HS] Mercurial

          Posté par  . Évalué à 2.

          Pour l'avoir malencontreusement utilisé sur une révision publique,

          Rectification! la fonction "rebase" ne permet pas de modifier des révisions publiques. Par contre il reste possible de repasser une version en "draft" puis de la modifier. Un message d'avertissement est affiché, il vaut mieux le suivre et renoncer (ou alors avoir beaucoup de temps à perdre).

          Par contre la fonction "strip" (qui sert à faire disparaître des commits) fonctionne quelque soit l'état du commit.

          Les vrais naviguent en -42

  • # intellij ou atom

    Posté par  . Évalué à 2.

    Je suis sous Linux, mais les appli que j'utilise sont dispo sous Zindozs.

    Si c'est dans le code Java, j'utilise Intellij pour résoudre le conflit, ça permet de vérifier instantanément si le code compile et on comprend ce qu'on est en train de faire.

    Sinon l'approche d'Atom est très sympa aussi pour la résolution de conflit, je l'utilise pour les conflits par exemple sur les rôles et les playbook Ansible .

  • # Beyond Compare

    Posté par  . Évalué à 3. Dernière modification le 19/03/21 à 20:04.

    Beyond Compare, mon préféré, mais c'est pas libre : https://www.scootersoftware.com/index.php.

    Pour la config de git : https://www.scootersoftware.com/support.php?zz=kb_vcs#gitwindows.

    Il est top je trouve pour la résolution de conflits.

    Par ailleurs, il permet de faire facilement la comparaison de plein de types de fichiers, par exemple des d'archives (pas la peine de décompresser manuellement en amont, elles apparaissent comme des dossiers).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.