Почему сообщество Git, кажется, игнорирует параллельные различия?

Раньше я использовал Windows, SVN, Tortoise SVN и Beyond Compare. Это была отличная комбинация для проверки кода.

Сейчас я использую OSX и Git. Мне удалось собрать bash-скрипт вместе с Gitx и DiffMerge, чтобы найти едва приемлемое решение.

Я путался с этой установкой, и подобными, больше года. Я также попытался использовать средство просмотра различий Github и средство просмотра различий Gitx, так что я не дал им ни единого шанса.

Есть так много умных людей, которые делают отличные вещи с Git. Почему бы не параллельный diff с возможностью просмотра всего файла? С людьми, которые использовали оба, я никогда не слышал, чтобы кто-то больше любил единственное представление +/-, по крайней мере, для быстрой проверки.

Я не могу говорить за Линуса об этом, но то, как git обращается с difftools, очень философски неверно. Git делает то, что делает очень хорошо, и использует внешние инструменты для всего остального, включая более сложные вычисления и слияние.

Я использую DiffMerge с git на OS X тоже, и мне не приходилось прибегать к оболочке bash. Это было сложно, но я настроил в git параметры difftool и mergetool для непосредственного вызова DiffMerge, и теперь я могу просматривать различия и разрешать конфликты слияний в отличном визуальном стороннем инструменте.

Вот мой конфиг:

[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

Вы заметите, что и сама SVN не предлагает параллельного решения. Вы перечислили сторонние инструменты. Как и в большинстве вещей в git, это необычайно настраиваемо, и оно имеет отличную поддержку инструментов из коробки. У вас есть Mergetool настроен? Если нет, вы должны. Если вы это сделаете, попробуйте git difftool. Затем взгляните на справочную страницу для параметров конфигурации.

Я использую KDiff3 в качестве моего mergetool, так как это хороший кроссплатформенный инструмент, и без дальнейшей настройки, git difftoolвыполняет именно то, что вы просите.

Это философия * nix. Многие люди, использующие эти инструменты, проводят много времени в терминале. Терминал не требует от нас перемещения рук от клавиатуры к мыши. Я знаю, что предпочитаю стиль +/- инструментам визуального сравнения / слияния, главным образом потому, что меня волнуют только различия. Я забочусь о 3-4 строках вокруг изменения и самого изменения. Все остальное - дополнительная информация, которая действительно мне не помогает.

Диффы обычно используются, чтобы быстро взглянуть на то, что было изменено. Не читать код.

Я никогда не находил инструменты визуального сравнения очень полезными по сравнению со стандартным режимом сравнения в системах GNU. Все, что они когда-либо заставляют меня делать, - это начать манипулировать мышью и заставить меня пролистать файл, выяснить их пользовательский интерфейс, а затем изо всех сил пытаться вернуться в командную строку, где я могу что-то сделать с проблемой, которую я вижу в diff ,

Из моего личного использования, я думаю, что ответ в основном заключается в том, что различия достаточно короткие, чтобы это не имело значения.

Для рецензирования кода я использую полнофункциональный инструмент рецензирования кода, который дает мне все, что мне нравится - например, комментарии, подсветку синтаксиса и параллельный просмотр.

Я использую git diffпочти исключительно во время постановки кода для фиксации; Когда это так, различия достаточно малы и достаточно недавние, поэтому мне не нужно видеть контекст, чтобы вспомнить, что происходит.

Мой инструмент для проверки кода , выбранный Phabricator , или, возможно, интегрированные в IDE инструменты, которые учитывают языковой контекст. Я думаю, что поток запросов запросов github ужасен для проверки кода, в основном потому, что он показывает унифицированный diff, а не бок о бок.