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 flavien75 . É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 freem . Évalué à 3.
Sous windows, il doit bien y avoir tortoiseGit, me semble?
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.
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 flavien75 . Évalué à 1.
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.
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.
Je n'y avais pas pensé, mais la pérennité est un argument fort.
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 ComputingFroggy (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 MrBidon . É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 flavien75 . Évalué à 2.
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 MrBidon . É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 flavien75 . Évalué à 1.
Pour le coup je n'ai jamais essayé de fusionner des commits.
Les vrais naviguent en -42
[^] # Re: [HS] Mercurial
Posté par flavien75 . Évalué à 2.
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 MrBidon . É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 AR7 (site web personnel) . Évalué à 3. Dernière modification le 19 mars 2021 à 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.