Должен ли я разбирать статус git или использовать gitsharp?

Question

Я хотел бы объединить git в производственный конвейер для создания 3dsmax-файлов. Хотя это нормально работать с git через TortoiseGit, я хотел бы связаться с ним из Maxscript, чтобы добавить пользовательские команды меню в 3dsmax.

Должен ли я разобрать git status текст вывода для определения статуса папки или использовать какой-либо инструмент для правильной связи с git?

Я думал о gitsharp, так как легко назвать объекты dotNet из Maxscript, но я не использовал внешние программы dotNet.

Answer 1

Моя собственная попытка решить эту проблему привела к анализу статуса git. Кажется чище и проще в реализации. С другой стороны, я ищу слова, чтобы создать специальный обработанный XML-файл, чтобы получить нужную информацию более «чистым» способом.

Answer 2

Я обнаружил git ls-files, и я полностью доволен его выходным форматом. git status был слишком ориентирован на человека для синтаксического анализа.

Я бы предпочел Mercurialgit с его командой статуса clear, но с большими двоичными файлами кажется, что git работает лучше для меня.

Answer 3

git обычно содержит «фарфор», команды высокого уровня, предназначенные для повседневного взаимодействия с пользователем, и «сантехника», которые являются командами низкого уровня, которые имеют простые, стабильные интерфейсы для сборки большего количества фарфора. Вы можете найти список в git man page. Чтобы использовать пример sergo, git ls-files - это водопровод для git status. Обертывание сантехники проще и безопаснее, чем фарфор, хотя может потребоваться некоторое озадачивание, чтобы выяснить, какие комплекты водопроводов соответствуют фарфору.

Answer 4

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

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

- Эно

Answer 5

С мерзавца версии 1.7.0, там был --porcelain вариант для git status. Выход:

git status --porcelain 

... предназначен для использования скриптов - компактное представление вывода, формат будет оставаться в разных версиях. Как страница человека говорит:

Фарфор Формат

Формат фарфора похож на короткий формат, но гарантированно не менять в обратном несовместимой пути между версиями Git или на основе пользовательской конфигурации , Это делает его идеальным для синтаксического анализа скриптов. Описание краткого формата выше также описывает формат фарфора, за некоторыми исключениями:

1. Конфигурация color.status пользователя не соблюдается; цвет всегда будет выключен.
2. Статус пользователя.Конфигурация relativePaths не соблюдается; показанные пути всегда будут относиться к корню репозитория.

Существует также альтернативный формат -z, рекомендованный для машинного разбора. В этом формате поле статуса одно и то же, но некоторые другие вещи меняются. Во-первых, -> опускается из записей переименования и порядок полей отменяется (например, от -> до перехода от). Во-вторых, NUL (ASCII 0) следует за каждым именем файла, заменяя пространство как разделитель полей и завершающую новую строку (но пространство по-прежнему отделяет поле статуса от первого имени файла). В-третьих, имена файлов, содержащие специальные символы, не являются специально отформатированы; не выполняется кавычка или обратная косая черта.

Итак, как говорится, вы можете также рассмотреть вопрос об использовании:

git status -z 

... для еще более надежной формат вывода.

Answer 6

Многие макс уже используют сборки .NET. Это должна быть самая легкая вещь для развития. Кроме того, анализ текста ... настолько хрупок. Я бы просто забыл о разборе текста.