И слияние и уведомление о коллизиях замечательно работают в гите уже сейчас. Даже с документами ББ. Проблема не в том, что это не делается. Проблема в том, что в случае коллизии система контроля версий только и сможет сказать "у вас коллизия". И чтобы с ней разобраться, придётся вручную сравнивать два документа.

слияние конфликтующих изменений

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

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

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

срабатывает только на уровне строк, насколько я знаю.

Если можно, лучше привести пример, при котором при слиянии веток произойдёт конфликт на уровне программы, при участии VCS в авто-слиянии.

Ну вот допустим есть некий модуль версии 1.0. В модуле две процедуры А() и В()
Два человека независимо друг от друга вносят изменения в свои копии этого модуля, т.е. появляются два потомка.

Сравнивая три файла (исходный и два потомка) мы обнаружим что каждая процедура:
1) Не изменялась ни у первого, ни у второго потомка
2) Изменялась только у первого
3) Изменялась только у второго
4) Изменялась у обоих

Понятно, что в первых трех случаях слияние можно сделать автоматически. А четвертый конфликтный вариант придется делать вручную.

Ну вот как то так.

Почему конфликтующих? Просто изменений.

Если хотите мое мнение глобальное, перспективное - то я за семантическое представление исходников

А всё, в конечном счёте, из-за не столь нужной фичи автослияния ))

...Клиент делает перепостановку задачи в начале месяца и просит внести изменения до конца месяца. На данный момент я эти изменения закодил, но не тестировал, т.е. отдать в продакшен не могу. Сегодня звонит клиент и говорит что нужно кровь из носа запилить дополнительную фичу до конца месяца. Ресурсов у меня не хватит на то и другое. Договариваюсь, что предыдущую задачу откладываем на след. месяц.
Обе задачи вносят изменения в логику одного и того же алгоритма, который, естественно, заключен в одном модуле. Сейчас я нахожусь на ревизии 469. Мне нужно вернуться к ревизии 450, выделить ветку и закодить вторую задачу. А в след. месяце нужно будет допилить задачу в первой ветке, и выполнить слияние.

Вот такой простой жизненный пример.

Вот такой простой жизненный пример.

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

В общем-то, потому что везде такая хреновая организация производства и возникают такие инструменты как merge в хранилищах.