Visual Git News

2021-10-31: Представляем Visual Git

Наконец-то я готов выпустить Visual Git (с реальными двоичными файлами, которые вы можете скачать) для широкой публики. Если вы не знаете, что это такое, это и фарфор Git (работающий автономно), и расширение IDE (с использованием стандарта интеграции системы управления версиями 90-х годов, который использовали MS и не-MS IDE … и все еще используют по сей день) . Это был кульминационный момент в работе с конца июня до настоящего времени. За это время мне удалось прикоснуться к множеству разных вещей, от резервного копирования на старые Windows API, до работы с малоизвестными, но задокументированными API Visual Studio, и в итоге я сделал то, что, по моему мнению, может быть полезно для людей. Я расскажу об основных трудностях, с которыми я столкнулся, а также о том, почему я изначально написал это.

Изначально я написал его наполовину, чтобы удовлетворить какое-то давнишнее желание, наполовину в шутку. Изначально я хотел что-то получше для управления версиями в моих ретро-проектах (копаться в старых вещах Windows — мое хобби), и подумал, что сопоставление Visual Basic и Git будет забавным. Однако я понял, что это действительно полезно. Почти наверняка существует множество Visual Basic и др. В дикой природе, которые могли бы работать с чем-то лучшим, чем SourceSafe. Каким бы увлекательным ни было разработка на старой системе, я не думаю, что кто-то захочет вернуться к шкурам медведя и каменным ножам централизованного контроля версий, которые они не могут эффективно использовать в современной системе.

Первоначальные проблемы: запуск Git и SCC

Во-первых, мне действительно приходилось иметь возможность даже использовать Git из более старой Windows (2000, потому что это разумное подмножество Win32 и хороший винтаж) и Visual Studio (SCC API достаточно гибок, чтобы поддерживать почти каждая 32-битная версия) Я хотел нацелиться. Очевидным выбором является libgit2, которая написана в основном на переносимом C89 и не требует другой реализации Git. Я также выбрал Visual C ++ 6 в качестве набора инструментов, отчасти для того, чтобы испытать, как это будет выглядеть с его помощью (в конце концов, это gcc 2.95 Windows), отчасти потому, что он генерирует небольшие двоичные файлы с низкой зависимостью, отчасти на случай, если я удалось собрать все это на Альфе (Однажды …). Нет проблем, CMake удалил поддержку для этого относительно недавно (так что я мог использовать 3.5), и проблем с CMakeLists в зависимостях этой версии не было. Однако мне пришлось убрать некоторые длинные и более новые способы использования Windows API (обычно связанные с символическими ссылками). Мне также нужно было собрать OpenSSL, zlib и libssh2. Внимательные читатели также заметят, что мне не нужен OpenSSL, потому что libgit2 может использовать WinHTTP, а libssh2 может использовать BCrypt. Однако первое ограничивает вас любым TLS, поддерживаемым хостом Windows, а второе требует Vista. Использование OpenSSL позволит использовать TLSv1.3 и SSH в старых системах. (В любом случае, все мои изменения доступны на GitHub.)

Следующим, с чем нужно было работать, был старый API плагина управления версиями Visual Studio. Он немного вводит вас в централизованную модель VCS, предоставляя фиксированный набор функциональных возможностей, которые не слишком хорошо соответствуют Git. Например, API предполагает модель извлечения, а затем возврата, но с Git извлечение — это совершенно другая операция, и вы можете зафиксировать, даже если у других есть копия. Я в основном просто сопоставил извлечение с nop, но в любом случае должен был реализовать его как флаг, потому что некоторые IDE зависят от возможности запрашивать, извлечен ли файл, прежде чем он может быть зафиксирован или даже отредактирован. В остальном сопоставление действий Git и SCC было на удивление гладким. Остальные функции Git могут быть реализованы путем перехода к новому интерфейсу.

Другая проблема с SCC API заключается в том, что не многие люди реализовали его, поэтому, хотя документация существовала, не на что можно было положиться, если что-то пойдет не так, кроме старых сообщений на форуме MSDN, в которых души пытались реализовать указанный API. Я столкнулся с некоторыми запутанными проблемами. Одна из таких проблем заключалась в том, что Visual C ++ оставил указатель на ранее инициализированный экземпляр при вызове SccInitialize (поскольку API может иметь несколько дескрипторов для повторного входа в несколько проектов) новому экземпляру, которому он должен передать дескриптор в выделенный блок для нового экземпляра. Это заставило меня ошибочно поверить, что это синглтон. Это меня достаточно смутило. Я разыскал сотрудника Microsoft, который отвечал на эти вопросы на форуме MSDN, который удобно написал сообщение, заставившее меня думать, что это предприятие возможно. В любом случае мне удалось разобраться самостоятельно. Прости, Алин!

Новое видение

Также было некоторое смещение прицела по пути. Изначально я собирался сделать только поставщика системы управления версиями для интеграции в IDE. Однако, чтобы раскрыть функциональность, которая существует только в Git и не предоставляется через фиксированную функциональность SCC, мне пришлось создать для нее пользовательский интерфейс (это было предоставлено API SccRunScc ). Тогда почему бы не отобразить, например, статус Git? В конце концов я понял, что у меня есть Git porcelain, и решил запустить как плагин SCC так и автономный porcelain. Фарфоровая деталь обошлась бы без старой IDE, даже на современной Windows.

Я думаю, что стремление к тому, чтобы фарфор был полезным сам по себе, привел меня к некоторым идеалам для этого проекта. Две мои лошади-любители хорошо использовали графический интерфейс (используя такие мелочи, как значки, чтобы показать различия) и очищали терминологию, используемую Git. Что касается первого, я действительно хотел воспользоваться преимуществами метафор, которые может использовать графический интерфейс, и которые не подходят для командной строки. Конечно, определенно есть вещи, которые стандартная командная строка Git может делать, а Visual Git не может, многое еще не реализовано — не потому, что графический интерфейс не может делать это хорошо. Для последнего перегруженная и сбивающая с толку терминология является одной из причин, почему Git имеет тенденцию быть непостижимым для многих пользователей. Вся сага о сценах и индексах — один мерзкий пример. Вот почему я пытаюсь выбрать что-то более очевидное, следить за тем, чтобы другие термины не описывали это, и придерживаюсь этого; например, я называю это стадией .

Еще я работаю с документацией. Хотя я не уверен, что это строго необходимо (большая часть пользовательского интерфейса должна показаться интуитивно понятной, а эксперименты с тем, с чем небезопасно), я думаю, что это будет полезно для объяснения сопоставления команд SCC и Git, из-за вышеупомянутых проблем с оформлением заказа. Я экспериментирую с палтусом, но я открыт для альтернатив. (Веб-сайт — еще одна проблема в моей стороне; все поле генератора статических сайтов настолько жирное и подавляющее, что я прибег к написанию HTML и M4 вручную. M4! Что со мной не так? )

Вот и все

В любом случае, я планирую в конечном итоге открыть его исходный код. В коде есть много вещей, которые я хочу очистить (такие как настройка среды сборки, некоторые из уродливых хаков и т. Д.), Прежде чем я буду чувствовать себя комфортно, публикуя его; когда я это сделаю, я обязательно дам знать людям. В конце концов, я не хочу, чтобы это оставалось на месте. Мне потребовалось время, чтобы почувствовать себя достаточно уверенно, чтобы выпустить общедоступные двоичные файлы! Конечно, как упоминалось ранее, вещи, которые мне нужно было изменить, находятся в ветках GitHub. А пока я хотел бы услышать ваш отзыв. Я также провожу опрос о том, что люди хотели бы видеть в Visual Git, из любопытства и оценки интереса. Я хотел бы услышать от вас, используете ли вы его и каковы ваши планы на этот счет! Если я получу ответ от людей, я, вероятно, найду возможность создать где-нибудь канал для обсуждения.

О, и, конечно же, вы можете получить Visual Git, щелкнув прямо здесь . ~ cb