Por que a comunidade Git parece ignorar as diferenças lado a lado?


33

Eu costumava usar Windows, SVN, Tortoise SVN e Beyond Compare. Foi uma ótima combinação para fazer revisões de código.

Agora eu uso o OSX e o Git. Consegui agrupar um script bash junto com o Gitx e o DiffMerge para encontrar uma solução quase aceitável.

Eu me atrapalho com essa configuração e outras semelhantes há mais de um ano. Também tentei usar o visualizador de diferenças do Github e o visualizador de diferenças do Gitx, por isso não é como se eu não tivesse lhes dado uma chance.

Há tantas pessoas inteligentes fazendo ótimas coisas com o Git. Por que não o diff lado a lado com a opção de ver o arquivo inteiro? Com pessoas que usaram os dois, nunca ouvi falar de alguém que goste mais do single +/-, pelo menos por mais que uma verificação rápida.


Você pode configurar o TortoiseGit para usar o Beyond Compare para diiffs, caso em que você veria o arquivo inteiro lado a lado (no entanto, eu nunca testei essa configuração pessoalmente [mas planejo, um desses dias]).
wildpeaks

1
Apenas um comentário, eu uso o Windows, SVN e Beyond Compare. Mas agora eu uso o Ubuntu + Git. Felizmente, ainda posso usar meu velho amigo Beyond Compare. Funciona muito bem no Ubuntu. E, embora não seja de graça, vale cada centavo para mim. :) Desculpe, não posso oferecer uma solução no OSX, mas não queria que as pessoas pensassem que o Beyond Compare era apenas uma solução para Windows.
David S

Sete anos depois, ainda me sinto assim, mas me treinei para preferir a diferença em linha em todos os casos, exceto nos mais complexos. Então eu rompo com meu velho amigo Beyond Compare.
Kyle Heironimus

Respostas:


19

Não posso falar por Linus sobre isso, mas o modo como o git lida com os difftools é muito unixish, filosoficamente falando. O git faz o que faz muito bem e usa ferramentas externas para todo o resto, incluindo diferenças e mesclagens mais sofisticadas.

Também uso o DiffMerge com git no OS X e não tive que recorrer a nenhum shell de bash. Foi complicado, mas configurei as configurações difftool e mergetool do git para chamar o DiffMerge diretamente, e agora posso visualizar diffs e resolver conflitos de mesclagem em uma excelente ferramenta visual de terceiros.

Aqui está a minha configuração:

[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

1
Isso está bem, mas quando vários arquivos são alterados, eu os olho um de cada vez, na ordem em que o git decide mostrá-los para mim. Eu devo fechar um para abrir outro. É por isso que eu também uso scripts bash quando quero ver todos os arquivos de uma só vez.
Kyle Heironimus

Não sei o que você espera ver em termos de "olhar para todos de uma vez". Mas confira git diff --stat. Fornece uma boa lista gráfica de todos os arquivos alterados, com o número de linhas alteradas.
Dan Ray

Pensando um pouco mais sobre essa coisa de "abrir todos de uma vez" ... Quantos arquivos você pode editar / visualizar de cada vez? Só posso olhar para um arquivo a qualquer momento. Eu acho que simplesmente não entendo o que você gostaria que ele fizesse.
Dan Ray

2
O melhor exemplo é o TortoiseSVN com Beyond Compare. Por exemplo, se o último commit de meu colega de trabalho tiver 3 arquivos alterados, ele mostrará os três arquivos em uma lista. Posso clicar no arquivo apropriado para ver as diferenças. Eu também poderia ter 3 janelas separadas, cada uma com o arquivo diferente. Posso então ir e voltar entre eles, conforme necessário para examinar a mudança. Basicamente, permite visualizar todas as alterações nos seus próprios termos, não em série na ordem ditada pelos seus vcs.
Kyle Heironimus

1
Você deve conferir a Tower. É o melhor Mac Git Gui que eu já vi, e faz o que você está falando e MUITO MAIS. git-tower.com
Dan Ray

16

Você notará que o próprio SVN também não oferece uma solução lado a lado. O que você listou são ferramentas de terceiros. Como na maioria das coisas no git, isso é extraordinariamente configurável e possui um ótimo suporte de ferramenta pronto para uso. Você tem uma ferramenta de fusão configurada? Se não, você deveria. Se sim, tente git difftool. Então dê uma olhada na página de manual para opções de configuração.

Eu uso o KDiff3 como minha ferramenta de fusão, uma vez que é uma boa ferramenta de plataforma cruzada e sem nenhuma configuração adicional, git difftoolfaz exatamente o que você está pedindo.


2
Na verdade, ele funciona bem com o difftool, mas ainda falha ao examinar muitos arquivos. Eles devem ser abertos um de cada vez. Para abri-los todos de uma vez, eu tenho que fazer o hackery do script bash.
Kyle Heironimus

9

É a filosofia * nix. Muitas pessoas que usam essas ferramentas passam muito tempo no terminal. O terminal não exige que movamos nossas mãos do teclado para o mouse. Sei que prefiro o estilo +/- às ferramentas de comparação / mesclagem visual, principalmente porque me preocupo apenas com as diferenças. Eu me preocupo com as 3-4 linhas em torno da mudança e da própria mudança. Mais alguma coisa é informação extra que realmente não me ajuda.

Diff's são comumente usados ​​para dar uma olhada rápida no que foi alterado. Não para ler o código.

Eu nunca achei as ferramentas de diferenças visuais muito úteis em comparação com as diferenças padrão nos sistemas GNU. Tudo o que eles me fazem fazer é começar a mexer com o mouse e me forçar a percorrer o arquivo, descobrir a interface do usuário e, em seguida, lutar para voltar à linha de comando, onde posso fazer algo sobre um problema que vejo no diff .


1
vimdiff está bom, geralmente mostra apenas as partes. Eu o uso para mesclagens; não é necessário mouse.
alternativa

8
Você já observou as alterações feitas por um colega de trabalho? Para áreas do código que você não conhece tão bem? Faço o tempo todo e não consigo imaginar fazê-lo sem lado a lado, todo o código. Para mim, o +/- é ótimo para alterações feitas pelo be, mas não para outros. Não estou dizendo que você está errado ou ruim ou algo assim. Só perguntando.
Kyle Heironimus

1
Costumo entrar em código alterado por colegas de trabalho, geralmente em áreas com as quais não estou familiarizado. Acho que já usei lado a lado talvez 3 ou 4 vezes e poderia facilmente ter ficado sem. Depende apenas do seu estilo de operação preferido. Funciona para você, acho desnecessário.
precisa saber é o seguinte

0

Do meu uso pessoal, acho que a resposta é principalmente que as diferenças são curtas o suficiente para que não importem.

Para revisões de código, eu uso uma ferramenta completa de revisão de código, que me fornece tudo o que eu gosto - como comentários, realce de sintaxe e exibição lado a lado.

Eu uso git diffquase exclusivamente durante a preparação do código para confirmação; Nesse caso, as diferenças são pequenas o suficiente e recentes o suficiente para que eu não precise ver o contexto para lembrar o que está acontecendo.

Minha ferramenta de revisão de código , Phabricator , ou possivelmente ferramentas integradas ao IDE, que reconhecem o contexto da linguagem. Eu acho que o fluxo de solicitação de pull do github é terrível para a revisão de código, principalmente porque mostra o diff unificado e não lado a lado.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.