Mercurial: объединение одного файла между ветками в одно репо

ВНИМАНИЕ: такое фиктивное слияние, которое рекомендовано @Martin_Geisler, действительно может вас испортить, если позже вы захотите сделать истинное слияние двух ветвей. Будет записано фиктивное слияние, в котором будет указано, что вы выполняете слияние в ветку, в которую выполнялось фиктивное слияние - вы не увидите изменений. Или, если вы объединитесь с другой веткой, изменения в этой другой ветке будут отменены.

Если все, что вам нужно, это скопировать весь файл из одной ветки в другую, вы можете просто сделать:

   hg update -r to-branch
   hg revert -r from-branch file
   hg ci -m 'copied single file from from-branch to to-branch

Если вы хотите выбрать разные части этого файла, тогда "hg record" будет полезно.

Я только что сделал это в своем домашнем каталоге .hgignore.

Если обе ветки внесли изменения в файл, который вы хотите сохранить, грязный трюк будет заключаться в том, чтобы создать слияние двух веток с помощью hg merge, возможно / возможно, в еще одной ветке, проверить это, а затем скопировать один файл между слиянием и переходом:

   hg update -r to-branch
   branch merge-branch
   hg merge -r from-branch
   hg ci -m 'temp merge to be discarded"
   hg update -r to-branch
   hg revert -r merge-branch single-file
   hg ci -m 'merged single-file from from-branch to to-branch"
   hg strip merge-branch

Стоит упомянуть: способ копирования одного файла между ветвями (или ревизиями, или от ревизии к слиянию, или ....) - это hg revert. Т.е.

   hg update -r Where-you-want-to-copy-to
   hg revert -r Where-you-want-to-copy-from file-you-want-to-copy
   ...
   hg ci

По некоторым причинам меня и некоторых моих коллег это ОЧЕНЬ смущает. revert == copy ... имеет смысл для некоторых шаблонов использования, но не для всех.

Неа. Mercurial работает на основе набора изменений.

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

% HGMERGE=internal:local hg merge     # keep my files
% hg revert --rev other-branch a.txt  # update a.txt to other branch
% hg commit -m 'Dummy merge to pick a.txt from other-branch.'

Может быть, это вам немного поможет.

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

hg update -r branch-merging-to
hg extdiff -p vimdiff -r branch-merging-from file-I-am-merging

Для этого вам нужно включить внешние инструменты в вашем .hgrc, что означает просто добавить эти строки:

[extensions]
hgext.extdiff =  

Один довольно простой способ получить желаемый результат - это сделать это в два этапа: сначала использовать graft, затем использовать histedit.

Скажем, это отправная точка, и вам нужно выбрать некоторые части C и D для объединения после E:

A---B---C---D
      \
       -E

Затем вы должны пересадить C и D поверх E:

A---B---C---D
      \
       -E--C'--D'

Затем используйте hg histedit для редактирования C' и D'. Во время редактирования вы можете внести любые изменения, которые захотите, но в этом случае вы просто вернете все ненужные файлы (или даже их части).

(Обратите внимание, что histedit edit работает путем временного обновления вашей рабочей папки для соответствия содержимому данного набора изменений, как если бы он еще не был зафиксирован. Таким образом, вы можете легко вернуть ненужные файлы, а затем hg histedit --continue, что фактически заменит отредактированный набор изменений.)

Итак, окончательный результат будет:

A---B---C---D
      \
       -E--C''--D''

Где '' ревизии были изменены по мере необходимости.

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