Я это и имею в виду. Смысл его в том чтобы пользоваться гитом на всех этапах до построения. А если ты написал, собрал и начал кидаться доками туда-сюда, то проще сразу версионировать в ворде

Угу. Маркдаун ложится в гит и будучи текстовым форматом вообще нормально отслеживается, ревьювится и управляется

Да, у нас выход доки в ворд, только для госзаказчика и госзаказ это только один из процессов

Ну вот судя по проблеме, отслеживать, ревьюить и управлять приходится в ворде, а мд на входе чисто для галочки. Я и уточняю, обусловлено ли это какими-то другими требованиями

Понятненько. Я упустил всю переписку, но что если отработать ревью в ворде и после этого конвертнуть согласованную версию обратно в мд и дальше уже диффом с текущим мд исходником внимательно всё накатить, чтобы довести контент до согласованного состояния? Такие итерации видятся наименее болезненными

С диффом не совсем понимаю как работать, такого опыта не было, а насчет внимательно накатить, тоже могут быть проблемы, когда правки требуют сделать срочно, в течении дня(. Есть вариант, что будет сделано это все по быстрому в ворде и отправлено заказчику. Вот может когда, время появится, уже можно будет как то смержить эти версии в исходниках.

Тут все таки чат docops.

Смысл работы с текстом как с програмным кодом в том, чтобы хранить историю изменений с обоснованием причин.

Через полгода смотреть на строчки договора и думать «ну зачем это пихнули».

В случае с маркдауном, гитом, гитлабом и программисткой гигиеной изменений, это все будет под контролем и не у «машеньки которая работала с этимм клиентом», а у всего коллектива

С вордом это адище, проходил много раз.

Кто-то один еще может способен держать под контролем, но с ростом количества людей оно превратится в кошмар

Так в течение дня вы правите в ворде, хоть в течение недели, пока заказчик не получит что хочет. Исходники при этом не трогаете. А когда заказчик получает свой финальный док, то вы конвертируете его в мд, который коммитите в отдельной ветке (в этом коммите и будет дифф, по которому вы можете пройтись, чтобы убедиться, что всё ок), по необходимости добавляете ещё правки отдельным коммитом, затем мердж. И вы получаете исходники в актуальном состоянии с историей изменений

Ого, какая тут дискуссия )

Конвертацией из Word обратно в MD не получить исходную структуру файлов

И даже исходную разметку не получить. И даже просто чистую разметку наверняка не получить без использования фильтров пандока.

Это вопрос экспериментов) должна быть симметричная структура

Пандок же не рандомно конвертит

reStructuredText:

..  admonition:: note

    Lorem Ipsum

Но Word рандомно разметку внутри себя делает)

Markdown:

> **Note:** Lorem Ipsum

Word:
Табличка в две ячейки, в первой картинка с восклицательным знаком, во второй "Lorem Ipsum"

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

Но можно обеспечить diff: взять свой исходный docx и docx от заказчика. Конвертировать и почистить одинаковым алгоритмом обратно в MD, посмотреть на разницу двух полученных текстов. Либо конвертировать оба docx в картинки и подиффать эти картинки. Так будет видно, где рамочку подвинули на пиксель.