База знаний представляет из себя набор из нескольких тысяч файлов

Вот это я понимаю «мёртвый груз знаний». Ты хоть оин файл открывал дважды?

По теме. Вообще-то так должно быть.

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

Дык перед правкой проапдейтить надо!

Ты хоть оин файл открывал дважды?

Постоянно пользуюсь.

Дык перед правкой проапдейтить надо!

Он не всегда возможен, например, нет сети.

странно, что git pull -s recursive -X theirs не мержит автоматом. ну попробуй фетчнуть remote master и сделать git merge -s ours

а чего у тебя -X theirs если «последние изменения» идут в твоем коммите?

Таскаешь на флешке?

Ну ты прям как маленький

Дык перед правкой проапдейтить надо!

Он не всегда возможен, например, нет сети.

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

странно, что git pull -s recursive -X theirs не мержит автоматом.

Да, не мержит. Лупит бомбу в файл.

ну попробуй фетчнуть remote master и сделать git merge -s ours

Мне нужна команда не разовая, а постоянная. Которая просто всегда запускается в качестве синхронизации и мержит по последним изменениям.

а чего у тебя -X theirs если «последние изменения» идут в твоем коммите?

Они могут где угодно идти. Они могут приходить с сервера, а могут быть локально. Я "-X theirs" и поставил в расчете на то, что при конфликтах будут устанавливаться хоть какие-нибудь изменения. Но конфликты автоматом не стали разрешаться.

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

Я же написал:

Это неудобно, и к тому же над базой знаний написана оболочка, которая перестает работать, если в корневом индексном XML-файле будет помечен конфликт (XML просто не распарсится). Приходится вручную править файл.

Гуглится

git --fetch
git reset --hard origin/master

Мне нужна команда не разовая,

ну так сделай ее постоянной, в чем проблема?

Они могут где угодно идти

как это где угодно? ты только что сделал коммит, как он может быть старее чем, то, что в удаленном репозитории?

git reset --hard origin/master

Это совсем не то, что ему нужно. Upd: потеряет все остальные изменения

Авто мерджа не добится в любом случае. Даже при ручном он поломает структуру xml, т.к. git AFAIK с ними никак по-особому не работает. Выход - принимать безоговорочно последнее изменение.

Так прикрути к своему поделию инкрементальные правки этого самого XML-а, т.е. не пересохраняй корневой файл каждый раз, а сохраняй правки к нему в структурированном формате («в ноде А изменили атрибут Б», «в ноду Ц добавили ноду Д»), потом в гуйце руками на уровне приложения эти правки и мерж.

Ладно, посмотрим на проблему с другой стороны

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

Не знаю, что у тебя там, и как, рискну только предположить.

Допустим, у тебя два компьютера (A, B), с которых ты работаешь, и некий сервер (S), с которым ты синхронизируешься.

Сначала везде всё одинаково:

S: a -> b -> c -> d
A: a -> b -> c -> d
B: a -> b -> c -> d

Допустим, на компьютере А ты добавил в свою базу новую статью про хомячков:

S: a -> b -> c -> d
A: a -> b -> c -> d -> e
B: a -> b -> c -> d

Запушил это на сервер:

S: a -> b -> c -> d -> e
A: a -> b -> c -> d -> e
B: a -> b -> c -> d

Потом с ноутбуком B ушёл в дальнее плавание, в далёкое безынтернетье. Там ты решил написать статью о кроликах.

S: a -> b -> c -> d -> e
A: a -> b -> c -> d -> e
B: a -> b -> c -> d -> f

Какая из версий e и f - последняя? f? Тогда с машины B пушишь с флагом "-f" свою «последнюю» версию на сервер.

S: a -> b -> c -> d *> f
A: a -> b -> c -> d -> e
B: a -> b -> c -> d -> f

Отметил звездочкой, потому что мастер на сервере обновлизнасилован.

На машине A дропаешь коммит e (потому он идёт сразу за последним «общим» коммитом в истории на А и S) и мержишь изменения из S. Конфликтов быть не должно, по идее.

Но это путь истинного ССЗБ, так ты потеряешь коммит e с ценной информацией про хомячков!

На машине A дропаешь коммит e (потому он идёт сразу за последним «общим» коммитом в истории на А и S) и мержишь изменения из S

Собственно, вот это - дроп «лишних» коммитов из A относительно ремоута + мерж из этого ремоута - и можно автоматизировать. Скрипт написать, чтоли.

Авто мерджа не добится в любом случае.

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

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

stackoverflow.com/questions/15544736/resolving-conflicts-how-to-accept-their-changes-automatically
stackoverflow.com/questions/10178733/mercurial-merge-auto-merging-certain-conflict-patterns
Обратите внимание на последний топик.

Если Git умеет делать это автоматически, то в чем смысл писать гит самому еще раз?

S: a -> b -> c -> d -> e (00.01)
A: a -> b -> c -> d -> f (00.02)
B: a -> b -> c -> d -> g (00.03)

при этом если между f и g нет конфликтов (если автомердж отрабатыват ОК, то на сервере должно быть

S: a -> b -> c -> d -> e (00.01) -> f (00.02) -> g (00.03)

иначе если конфликты есть, то

S: a -> b -> c -> d -> e (00.01) -> g+(f-конфликты(f,g)) (00.03)

где g+(f-конфликты) означает, что в g добавились только те части коммита f, которые не конфликтовали с g

после этого корректность внешним образом (скриптом) проверяется синтаксиса XML (соответствие формату, соответствие схеме). Это нужно, чтобы База Знаний не сломалась при запуске от неправильного формата файла.

если при проверке формата всё ОК, то остается текущее состояние (g+(f-конфликты)).

иначе сервер ревертается на коммит/два назад (в изначально состояние сервера до мерджа конфликтующих бранчей), и потом накатывается самый новый из двух конфликтующих коммитов, то есть

S: a -> b -> c -> d -> e (00.01) -> g (00.03)

Теперь ТС представляет какой геморой имеют те кто поддерживает 2 ветки софта с общей кодовой базой но различными интерфейсами.

Скрипт напиши.

Ага, и запусти его под виндой. Прога база знаний то кроссплатформенная.

Поэкспериментировал еще.

Таки опция -X theirs нормально работает.

Просто на третьем рабочем месте ее не было в команде синхронизации, а я не обратил на это внимание.

Конечно, -X theirs немного не то что нужно, она не ориентируется по времени, а просто считает изменения «на той стороне» более главными. А так как «та сторона» - это сервер синхронизации, то правило получается «главный-сервер».