Is it possible to merge binaries with conflict resolution, and if not, why are there no solutions on this topic?

Question

git

Доброй ночи всем!
Наверное, знакомая всем ситуация, когда в обеих ветках есть измененный бинарный файл (например, png), и изменения в обеих ветках важны. То есть, нужно слить два файла в один. С текстовыми это сделать проблемы не составляет, но с бинарными я нашел лишь одно решение - выбрать между двух версий.
Я, конечно, понимаю, что вопрос объединения бинарников с учетом изменений в обеих ветках скорее из области фантастики, т.к. это невозможно в силу их структуры, но, может, встречаются хоть какие-то - любые - исключения (пусть и гипотетически, например, указать гиту путь до компилятора, путь до ресурсов и дать ему скомпилировать новый файл из объединенных ресурсов)? Или это все-таки полностью невозможно?
Adobe, например, могли бы выпустить такой компилятор. Указываешь гиту путь до psd обеих версий... он при помощи этой тулзы мержит слои, компилирует в png и вуаля! Почему этого до сих пор нет - никому не нужно, или слишком сложно в реализации (а это непросто)?
Всегда оставляю возможность, что я чего-то не знаю или о чем-то не слышал, поэтому такой вопрос)
Спасибо!

Answer 1

Теоретически можно, ведь можно указывать mergetool, если хочется. Другой вопрос - как из этого построить что-то работающее. Текст - это такая удобно нормализованная штука - есть строчки, в нормальном тексте они короткие, делятся переводом строки - удобный элемент для квантования целого ресурса. С бинарниками так просто уже не поступишь: во-первых, для каждого формата свой подход (а для текста совершенно разного назначения вполне можно использовать одну и ту же тулзу), а во-вторых - нужно уметь собственно совмещать то, что в картинках различается. Некоторые форматы, например PSD, вполне можно было бы смержить в ситуациях, когда разные люди добавили разные слои и работали каждый в своих.
Я думаю все дело в соотношении простота/спрос. Написать тулзу еще нужно суметь, ведь это в тексте достаточно просто вставить строки друг за другом, а в PSD нужно полностью всю служебную инфу обновить и вообще правильно записать весь формат, плюс нужно продумать естественное поведение в каждой конфликтной ситуации, а в сложных форматах их намного больше, чем в тексте - один дизайнер слой переименовал, а другой - нет, и оба чтото поменяли, нужно определить - мержить изменения в один слой или оставлять два разных. И еще миллион таких ситуаций со всем, что может храниться в PSD. А спрос-то не сильно велик - тут и программистам-то не всем нравится ветвление (и часто бывает оно и правда только усложняет процесс), а дизайнерам поди разжуй. Так что идея ваша вполне заслуживает внимания, просто при реализации она превращается во вполне конкретные частные решения, которые подаются вместе с основным инструментом, и не предназначены для работы с VCS общего назначения (Git, Mercurial).
Вот под рукой отличный пример: команда Dr. Explain - тулзы для создания документации - недавно запустили сервис совместной работы. И фишка вся в том, что это более чем хорошая новость для пользователей этого продукта, т.к. их формат хранения практически не подлежит мержу средствами обычных VCS (это xml-ка, которая хранит внутри себя ВСЕ, в том числе картинки). Вот они и выкатили свой велосипед. Мы кстати пытались использовать это дело, сделали штук 6 коммитов в свой репозиторий, быстро поняли, что работать надо по-очереди, т.к. смержить просто нереально, а потом, пока еще не поздно, съехали на DocBook (с компиляцией в XSL-FO).
P.S. Не так уж и не нужно - в перфорс есть оказывается такие приложения для мержа: www.perforce.com/helix-apps

Answer 2

Это никому не нужно
поэтому и инструментов нет
а так можно каким нибудь дифом сравнить