“мерзавец объединяется-s, их” было нужно — но я знаю, что это не существует
У меня есть много удаленных репозиториев, которые я хочу объединить вместе. Некоторые поддеревья в тех репозиториях уникальны для удаленного (они содержат данные, которые являются определенными для хоста), другие поддеревья содержат данные, которые являются (предположены быть) распространены через все пульты ДУ.
То, что я хочу сделать, по существу, выполняется "получение по запросу мерзавца" для каждого удаленного. Этот будет ускоренная перемотка вперед локальное основное ответвление вдоль ответвления отслеживания для удаленного ведущего устройства для определенных для хоста файлов, которые изменились на удаленном, и ничего не сделают для общих файлов, потому что они не будут изменяться.
Изменение в общем файле (называют это F, при этом изменение F') не должно быть проблемой, даже если это только происходит на одном удаленном сначала. слияние мерзавца Сделает Правильную Вещь и даст мне копию F' в моей составной рабочей области, которая является тем, что я хочу. Проблема возникает, если тот же общий файл изменяется по-другому на другом удаленном (назовите это F"). слияние мерзавца даст мне составной объект F' и F", который не является тем, что я хочу. Все, что я хочу, является F".
Когда я работал с ClearCase, мы назвали это слиянием копии. Результатом слияния всегда была точная копия участника. Это много кажется, что "мерзавец объединяется-s, их" был бы, за исключением того, что это не существует.
Я задающийся вопросом, могу ли я приготовить что-то с "деревом чтения мерзавца-m - тривиальный" для избавлений от слияний ускоренной перемотки вперед, затем сделайте некоторое волшебство со слиянием мерзавца и пользовательским mergetool, который просто копирует файл $REMOTE в $MERGED. Но даже с этим я не вижу, как я могу мешать слиянию мерзавца составить F' и F", если это вещи слияние тривиально.
Я читал, ссылка - там "их", версия "мерзавца объединяется-s наш"? на этом сайте и сообщении Junio Hamano это ссылается на объяснение, почему "слияние мерзавца-s их" является такой плохой идеей, но это не имеет место для меня. Я действительно оцениваю старую историю, но я должен дезертировать с корабля и следовать за изменением на удаленном сайте, когда каждый происходит. Никакая новая работа не сделана на локальном сайте. Это просто должно сформировать составной объект всех удаленных сайтов, брать последний "общий" файл от последнего опросило удаленный, когда каждый изменяется.
Заранее спасибо за любую справку можно дать мне.
3 ответа
(обновление 2011 г .:
Ответ « команда git для создания одной ветки похожей на другую » перечисляет все возможные способы имитации git merge -s theirs` )
Для Для конкретных файлов / деревьев, которые вы хотите скопировать-слить, вы можете установить значение gitattributes , подобное тому, которое я упоминаю в этом вопросе SO , определяя собственный драйвер слияния.
Сценарий, связанный с атрибутом слияния, обеспечит постоянное сохранение удаленного файла в качестве результата слияния (см. Этот ответ SO для иллюстрации, хотя и для противоположного сценария - сохранение локальной версии).
echo * merge=keepTheir > dirWithCopyMerge\.gitattributes
git config merge.keepTheir.name "always keep theirduring merge"
git config merge.keepTheir.driver "keepTheir.sh %O %A %B"
Автор установив атрибут .git в верхней части поддерева, которое вы хотите скопировать-слияние, с ' * merge = keepTheir ' в качестве его содержимого, вы фактически приписываете настраиваемый драйвер слияния всем файлам этого поддерева ( обратите внимание на использование подстановочного знака « * »).
С keepTheir.sh как:
mv -f $3 $2
exit 0
вам не нужно изменять какой-либо драйвер слияния по умолчанию, и вы применяете свой собственный только на нужные файлы.
Большое спасибо @VonC за предложение использовать атрибут merge=custom-driver в файле .gitattributes - -. Хотя это сработает, я не хочу загрязнять своё рабочее пространство .git-файлами, и хотя я мог бы использовать $GIT_DIR/info/атрибуты , чтобы избежать загрязнения, меня беспокоит необходимость 2 правил для перехвата точечных и не точечных файлов.
После небольшого эксперимента мне удалось получить решение с работающей переменной конфигурации merge.default (упомянутой в manpage gitattributes(5)). Хитрость, которую я пропустил, заключалась в том, что merge.default принимает имя пользовательского драйвера, который вы определили ранее; вы не даёте ему непосредственно пользовательскую команду . Вот что мне подходит...
Сначала определите свой собственный драйвер копирования. Вы можете использовать команды оболочки напрямую; нет необходимости во внешнем скрипте (просто убедитесь, что вы правильно цитируете мета-символы оболочки):
git config merge.copy-merge.name 'Copy Merge'
git config merge.copy-merge.driver 'mv %B %A'
Обратите внимание, что mv возвращает 0 при успешном, 1 при неудачном, удовлетворяя критериям сообщения об "успешном" слиянии обратно в git.
Теперь скажите git'у, что ВСЕ слияния - это копирование:
git config merge.default copy-merge
Эй, Presto! Работа сделана. gitовое слияние
Если вы хотите выполнить слияние без копирования, просто сбросьте драйвер слияния по умолчанию:
git config --unset merge.default
Если вы хотите быть более избирательным, то оставьте merge.default неустановленным и используйте атрибуты, как написано в @VonC:
cd path/to/copy-merge/in
echo '* merge=copy-merge' > .gitattributes
echo '.* merge=copy-merge' >> .gitattributes
Сделайте это в верхней части каждого поддерева, в которое вы хотите скопировать-merge. Если есть поддерево, в которое Вы не хотите копировать, Вы можете выключить его снова:
cd path/to/copy-merge/in/path/to/normal-merge/in
echo '* merge' > .gitattributes
echo '.* merge' >> .gitattributes
WARNING: засорение Вашего рабочего дерева большим количеством файлов .gitattributes обязательно приведет к путанице, особенно если Вы также используете такие вещи, как "*.bin -merge" в других каталогах, чтобы заставить все слияния .bin-файлов не срабатывать с конфликтами. Может быть лучше использовать $GIT_DIR/info/атрибуты для такого рода вещей, так как он имеет наивысший приоритет.
.В версии 1.7.1 Git вы можете передать «их» стратегию для слияния с аргументом «-Xtheirs».
git merge -Xtheirs otherBranch
Не уверен, применимо ли это к тому, что вы пытаетесь сделать, но, вероятно, стоит попробовать.
(См. Также этот связанный вопрос )