Порекомендуйте CLI альтернативы RCS merge

vimdiff нечто между, сойдет?

vimdiff это не CLI, а консольный интрефейс. Мне нужно скриптовать.

Скриптовать, простите, что? Разрешение конфликтов? Ну так кушай выхлоп rcsmerge и вперед, раз умеешь их разрешать.

Или ты не умеешь? Тогда pijul попробуй, потом отпишешься, вместе поржем.

GNU Emacs

При чем тут pijul?

Там нет merge conflicts.

Я знаю, но тогда как понимать

вместе поржем

?

Потому что см ответ на последний вопрос https://pijul.org/faq

Справедливо.

vimdiff вполне можно скриптовать. Примерно с тем же успехом как gdb например. Для того, чтобы понять, что ты никак не сможешь автоматизировать разрешение конфликтов - тебе должно хватить.

Есть ещё patch --merge=diff3. Но страток там нет.

Там нет merge conflicts

Как раз на днях думал, что неплохо было бы сделать некое хранилище данных в стиле центрального сервера и ленивых кэшей клиентов, которые бы без ошибок сливали изменения клиентов с центральным хранилищем. Конечно, для данных с тесными логическими взаимосвязями, вроде бухгалтерии или исходных кодов, оно не подойдет. А для менее ответственной инфы — вполне себе.

Правда, после прочтения механизма разрешения конфликтов:
https://jneem.github.io/pijul/
выяснилось, что автору просто нравится писать много статей. По сути, проблема конфликтов не решена никак — просто эта софтина аккуратно преобразует и складирует конфликты. Причем, после наложения нескольких слоев конфликтов она уже начинает выдавать откровенную дичь (пример там же).

Именно поэтому во всех VCS софтинах принято конфликты решать на месте, а не откладывать. Однако же, «отсутствие» конфликтов продается как ключевая фича Pijul... которой у нее на самом деле нет.

Сначала мне показалась интересной их идея про слияние с учетом промежуточных версий для уточнения результата слияния:

https://tahoe-lafs.org/~zooko/badmerge/simple.html

Однако, для того, чтобы действительно эффективно реализовать такой алгоритм, нужно регистрировать изменение каждой буквы. По крайней мере при генерации различий, чтобы определить для случая правки

A

на

A
A

A

B

Классическое трехстороннее слияние выдаст всегда

B
A

мама мыла раму -> моя мама мыла раму
мама мыла раму -> папа мыл раму
моя мама мыла раму + папа мыл раму => моя папа мыл раму

С другой стороны, общая идея обоих правок сохранилась, и авось никто не умрет, если моя папа помоет раму.

потому что давно уже пора написать diff с учётом языка программирования, а не тупые строчки, чтобы в диффе было: добавлена/переименована функция/переменная/декларация типа, блок перемещён внутрь условия, переменная сделана глобальной и т.п. Тогда и конфликты будут решаться. Например, я переименовал функцию и чего-то в хвост добавил. А другой человек поправил возвращаемый тип. Текстовый дифф уйдёт в отказ на таком, а проблема-то - ерундовая, если будет инфа о семантике у диффа.

Описываемая тобой проблема решается уже на уровне работы с посимвольной разницей, без необходимости анализа семантики. Все-таки семантику довольно тяжело анализировать, особенно если это какой-то C++, где она неподъемная. В крайнем случае делать синтаксическое разбиение и трактовать каждую синтаксический элемент как отдельную строчку, а сам перевод строки становится еще одним синтаксическим элементом, таким образом разбиение строки или слияние становится не более чем добавлением/удалением строки в терминах обычного diff.

Правда, первая проблема, которая сразу возникает при таком подходе — как реализовать эффективных алгоритм для поиска оптимальной разницы.