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

33

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

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

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

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

git

— Кайл Хейронимус
источник

Вы можете настроить TortoiseGit на использование Beyond Compare для различий, и в этом случае вы увидите весь файл рядом друг с другом (однако я никогда не проверял эту настройку лично [но планирую, на днях]).

— Wildpeaks

1

Просто комментарий, я использую для использования Windows, SVN и Beyond Compare. Но теперь я использую Ubuntu + Git. К счастью, я все еще могу использовать моего старого друга Beyond Compare. На Ubuntu работает отлично. И хотя это не бесплатно, оно стоит каждой копейки для меня. :) Извините, я не могу предложить вам решение для OSX, но не хотел, чтобы люди думали, что Beyond Compare - это решение только для Windows.

— Дэвид С

Спустя 7 лет я все еще чувствую себя таким образом, но я научил себя предпочитать встроенный diff во всех случаях, кроме самых сложных. Тогда я разрываю моего старого друга Beyond Compare.

— Кайл Хейронимус

19

Я не могу говорить за Линуса об этом, но то, как 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

— Дэн Рэй
источник

1

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

— Кайл Хейронимус

Я не знаю, что вы ожидаете увидеть с точки зрения «взглянуть на них всех сразу». Но проверить git diff --stat. Дает вам хороший графический список всех измененных файлов с количеством измененных строк.

— Дэн Рэй

Подумав еще немного об этой вещи «открыть их все сразу» ... Сколько файлов вы можете редактировать / просматривать одновременно? Я могу смотреть только на один файл в любой момент. Я думаю, я просто не понимаю, что вы хотели бы это сделать.

— Дэн Рэй

2

Лучший пример - TortoiseSVN с Beyond Compare. Например, если последний коммит моего коллеги изменил 3 файла, он покажет три файла в списке. Затем я могу нажать на соответствующий файл, чтобы увидеть различия. Я также мог бы открыть 3 отдельных окна, каждое с другим файлом. Затем я могу переходить туда-сюда между ними, по мере необходимости, чтобы изучить изменения. По сути, это позволяет вам просматривать все изменения на ваших собственных условиях, а не последовательно в порядке, продиктованном вашими vcs.

— Кайл Хейронимус

1

Знаешь, тебе стоит проверить Башню. Это лучший Mac Git Gui, который я когда-либо видел, и делает то, о чем вы говорите, и еще больше. git-tower.com

— Дэн Рэй

16

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

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

— Райан Стюарт
источник

2

На самом деле, это нормально с difftool, но все равно не удается при просмотре большого количества файлов. Они должны быть открыты по одному за раз. Чтобы открыть их все сразу, мне нужно взломать bash-скрипт.

— Кайл Хейронимус

9

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

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

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

— jsternberg
источник

1

с vimdiff все в порядке, обычно он показывает только части. Я использую это для слияния; мышь не нужна.

— альтернатива

8

Вы когда-нибудь смотрели на изменения, сделанные коллегой? С областями кода, с которыми вы не так знакомы? Я делаю все время, и я не могу себе представить, чтобы делать это без бок о бок, весь код. Для меня +/- отлично подходит для изменений, сделанных be, но не для других. Не говорю, что ты не прав, плох или еще что. Просто спрашиваю.

— Кайл Хейронимус

1

Я часто сталкиваюсь с кодом, измененным коллегами, часто в областях, с которыми я не знаком. Я думаю, что я использовал бок о бок, может быть, 3 или 4 раза, и мог бы легко обойтись без. Это зависит только от того, какой стиль работы вы предпочитаете. Это работает для вас, я считаю это ненужным.

— Брайан Ноблаух

0

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

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

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

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

— авив
источник