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

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

Начиная с версии git 1.7.0, для git status была опция --porcelain. Результат:

git status --porcelain

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

Фарфоровый формат

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

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

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

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

git status -z

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

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

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

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

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

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

-- хенон

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