Pourquoi la communauté Git semble-t-elle ignorer les différences côte à côte [fermé]

33

J'avais l'habitude d'utiliser Windows, SVN, SVN Tortoise et Beyond Compare. C'était une excellente combinaison pour faire des revues de code.

Maintenant, j'utilise OSX et Git. J'ai réussi à combiner un script bash avec Gitx et DiffMerge pour proposer une solution à peine acceptable.

Je me suis embrouillé avec cette configuration, et similaires, pendant plus d'un an. J'ai également essayé d'utiliser le visualiseur de diff Github et le visualiseur de diff Gitx, alors ce n'est pas comme si je ne leur avais pas laissé leur chance.

Il y a tellement de gens intelligents qui font de bonnes choses avec Git. Pourquoi ne pas le diff côte à côte avec la possibilité de voir le fichier entier? Avec des gens qui ont utilisé les deux, je n'ai jamais entendu parler de quelqu'un qui aime mieux la vue simple +/-, du moins pour plus d'un contrôle rapide.

git

— Kyle Heironimus
source

Vous pouvez configurer TortoiseGit pour qu’il utilise Beyond Compare pour diiffs, auquel cas vous verrez le fichier complet côte à côte (cependant, je n’ai jamais testé cette configuration personnellement [mais j’ai l’intention de le faire]).

— paroles sauvages

1

Juste un commentaire, j’utilisais Windows, SVN et Beyond Compare. Mais maintenant, j'utilise Ubuntu + Git. Heureusement, je peux toujours utiliser mon vieil ami Beyond Compare. Cela fonctionne très bien sur Ubuntu. Et bien que ce ne soit pas gratuit, cela vaut chaque centime pour moi. :) Désolé, je ne peux pas vous proposer de solution sur OSX, mais je ne voulais pas que les gens pensent que Beyond Compare était une solution exclusivement Windows.

— David S

7 ans plus tard, je le ressens encore un peu, mais je me suis entraîné à préférer le diff en ligne dans tous les cas, sauf les plus complexes. Puis j'éclate mon vieil ami Beyond Compare.

— Kyle Heironimus

19

Je ne peux pas parler pour Linus à ce sujet, mais la façon dont git gère difftools est très unixish, philosophiquement parlant. git fait ce qu’il fait très bien et utilise des outils externes pour tout le reste, y compris des fonctions de diffing et de fusion plus sophistiquées.

J'utilise aussi DiffMerge avec git sous OS X et je n'ai pas eu besoin de recourir à un shell bash. C'était délicat, mais j'ai configuré les paramètres difftool et mergetool de git pour qu'ils appellent directement DiffMerge. Je peux maintenant afficher les diffs et résoudre les conflits de fusion dans un excellent outil tiers visuel.

Voici ma config:

[mergetool "diffmerge"]
        cmd = "diffmerge --merge --result=\"$MERGED\" \"$LOCAL\" \"$(if test -f \"$BASE\"; then echo \"$BASE\"; else echo \"$LOCAL\"; fi)\" \"$REMOTE\""
        trustExitCode = false
[difftool "diffmerge"]
        cmd = diffmerge \"$LOCAL\" \"$REMOTE\"
[merge]
        tool = diffmerge
[diff]
        tool = diffmerge

— Dan Ray
source

1

Cela ne pose pas de problème, mais lorsque plusieurs fichiers changent, je peux les examiner un à un, dans l’ordre dans lequel git décide de me les montrer. Je dois en fermer une pour en ouvrir une autre. C'est pourquoi j'utilise également des scripts bash lorsque je souhaite consulter tous les fichiers en même temps.

— Kyle Heironimus

Je ne sais pas ce que vous vous attendriez à voir en termes de "les regarder tous en même temps". Mais vérifiez git diff --stat. Vous donne une belle liste graphique de tous les fichiers modifiés, avec le nombre de lignes modifiées.

— Dan Ray

En réfléchissant un peu plus à cette question "ouvrez-les tous en même temps" ... Combien de fichiers pouvez-vous éditer / afficher à la fois? Je ne peux regarder qu'un seul fichier à la fois. Je suppose que je ne comprends tout simplement pas ce que vous souhaiteriez.

— Dan Ray

2

Le meilleur exemple est TortoiseSVN avec Beyond Compare. Par exemple, si le dernier commit de mon collègue a 3 fichiers modifiés, les trois fichiers de la liste s'afficheront. Je peux ensuite cliquer sur le fichier approprié pour voir les différences. Je pourrais aussi avoir 3 fenêtres séparées ouvertes, chacune avec le fichier différent. Je peux ensuite aller et venir entre eux, au besoin, pour examiner le changement. En gros, cela vous permet d’afficher toutes les modifications selon vos propres termes et non en série dans l’ordre dicté par votre vcs.

— Kyle Heironimus

1

Vous savez, vous devriez vérifier Tower. C'est le meilleur Mac git gui que j'ai jamais vu, et fait ce dont vous parlez et bien plus. git-tower.com

— Dan Ray

16

Vous remarquerez que SVN n’offre pas non plus de solution côte à côte. Vous avez énuméré des outils tiers. Comme avec la plupart des choses dans git, ceci est extraordinairement configurable et offre une excellente prise en charge des outils. Avez-vous un logiciel mergetool ? Si non, vous devriez. Si vous le faites, essayez git difftool. Consultez ensuite la page de manuel pour les options de configuration.

J'utilise KDiff3 comme outil de fusion parce que c'est un outil multi-plateforme agréable, et sans configuration supplémentaire, git difftoolfait exactement ce que vous demandez.

— Ryan Stewart
source

2

En fait, cela ne pose pas de problème avec difftool, mais échoue quand on regarde beaucoup de fichiers. Ils doivent être ouverts un à la fois. Pour les ouvrir tous en même temps, je dois faire du hackery de script bash.

— Kyle Heironimus

9

C'est la philosophie * nix. Beaucoup de ceux qui utilisent ces outils passent beaucoup de temps dans le terminal. Le terminal ne nécessite pas que nous passions les mains du clavier à la souris. Je sais que je préfère le style +/- aux outils de différenciation / fusion visuelle, principalement parce que je ne me soucie que des différences. Je me soucie des lignes 3-4 autour du changement et du changement lui-même. De plus, ce sont des informations supplémentaires qui ne m'aident vraiment pas.

Les difficultés sont couramment utilisées pour obtenir un aperçu rapide de ce qui a été changé. Ne pas lire le code.

Je n'ai jamais trouvé les outils de visualisation visuels très utiles comparés au diff par défaut sur les systèmes GNU. Tout ce qu'ils me font faire, c'est commencer à jouer avec la souris et à m'obliger à faire défiler le fichier, à comprendre leur interface utilisateur, puis à lutter pour revenir dans la ligne de commande où je peux faire quelque chose à propos d'un problème que je vois dans le diff .

— Jsternberg
source

1

vimdiff va bien, il ne vous montre généralement que les parties. Je l'utilise pour les fusions; pas de souris nécessaire.

— Alternative

8

Avez-vous déjà examiné les modifications apportées par un collègue? Aux zones du code que vous ne connaissez pas aussi bien? Je fais tout le temps, et je ne peux pas imaginer le faire sans côte à côte, tout le code. Pour moi, le +/- est idéal pour les modifications apportées par be, mais pas pour les autres. Ne dis pas que tu as tort ou mal ou quoi que ce soit. Je ne faisais que demander.

— Kyle Heironimus

1

Je retourne souvent dans un code modifié par des collègues, souvent dans des domaines que je ne connais pas bien. Je pense que je l'ai utilisé côte à côte peut-être 3 ou 4 fois et que je n'aurais jamais pu m'en passer. Cela dépend de votre style d'exploitation préféré. Cela fonctionne pour vous, je trouve cela inutile.

— Brian Knoblauch le

0

De mon usage personnel, je pense que la réponse est principalement que les différences sont suffisamment courtes pour que cela ne soit pas grave.

Pour les révisions de code, j'utilise un outil complet de révision de code, qui me donne tout ce que j'aime, comme les commentaires, la coloration syntaxique et la vue côte à côte.

J'utilise git diffpresque exclusivement lors de la mise en place du code à valider; Lorsque c'est le cas, les différences sont suffisamment petites et récentes pour que je n'ai pas besoin de voir le contexte pour me rappeler ce qui se passe.

Mon outil de choix du code , Phabricator , ou peut-être des outils intégrés à l'EDI, tenant compte du contexte linguistique. Je pense que le flux de demandes de github est terrible pour la révision de code, principalement parce qu'il affiche un diff unifié et non pas côte à côte.

— aviv
source