Подтвердить что ты не робот

Mercurial - просмотреть список файлов, которые необходимо вручную объединить?

Есть ли команда Mercurial, которую вы можете использовать после hg pull, чтобы увидеть список всех файлов, которые необходимо будет вручную объединить (т.е. конфликты) при выполнении hg merge?

4b9b3361

ОТВЕТЫ

Ответ 1

hg resolve --list

В документации :

Слияния с неразрешенными конфликтами часто являются результатом неинтерактивного слияния с использованием внутреннего параметра конфигурации слияния или инструмента слияния командной строки, такого как diff3. Команда разрешения используется для управления файлами, связанными с слиянием, после запуска hg merge и до выполнения hg commit (т.е. Рабочий каталог должен иметь двух родителей).

Редактировать 5 января 2012 года:

(Сегодня я получил вчерашний голос за этот ответ, поэтому я его пересмотрел. Я обнаружил, что я не понял этот вопрос.)

Вопрос: "Я выполнил попытку из удаленного репозитория и еще не выполнил слияние. Могу ли я увидеть, какие конфликты будут созданы при выполнении слияния?"

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

Предположим, вы клонировали репозиторий A из какого-то удаленного источника в репозиторий B в вашей локальной системе, т.е. hg clone http://hg.example.com/A B. После этого вы вносите изменения в свой локальный репозиторий, B, которые включают по крайней мере одно коммит. Тем временем изменения были внесены в репозиторий A, так что, когда вы делаете pull, вы получаете сообщение о том, что были добавлены новые изменения и созданы головки.

На этом этапе вы можете сделать hg heads, чтобы перечислить два набора изменений, которые будут задействованы в слиянии. Из этой информации вы можете выдать команду статуса, чтобы перечислять различия между головами. Предполагая, что номера версий в вашем репозитории B, согласно списку глав, являются "1" и "2", то вы можете сделать hg status --rev 1:2, чтобы просмотреть список изменений.

Конечно, это не говорит о том, будут ли конфликты возникать при слиянии. Поскольку нет команды, которая покажет вам это, вам придется "просмотреть" слияние путем клонирования в новый репозиторий и выполнения слияния. Итак, hg clone B C && cd C && hg merge. Если вы удовлетворены результатом этого слияния, вы можете сделать hg com -m 'Merging complete' && hg push && cd ../ && rm -rf C.

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

Ответ 2

Если я сам не ошибаюсь, ответы выше, похоже, не затрагивают вопрос, который, как мне кажется, спрашивают: у меня есть два ветки в моем репозитории, которые я хотел бы объединить, и я хочу знать, что конфликты будут возникать (например, прежде чем каждый раз переходить к разрешению конфликта).

Чтобы сделать это, я бы слился с инструментом :merge3 (который пытается объединиться автоматически, но не разрешает конфликты), а затем используйте hg resolve --list - или просто посмотрите на вывод команды merge - чтобы увидеть конфликты.

hg merge <otherbranch> --tool :merge3
hg resolve -l

Если вы действительно не захотите объединиться в конце (если вы просто хотите увидеть, что будет конфликтом), вы можете запустить hg update -C после этого, чтобы отменить слияние.

Если вы хотите завершить слияние, вы можете запустить hg resolve <filepath> для каждого файла или просто hg resolve --all, чтобы пройти все, что осталось с конфликтами, перед тем, как вы hg commit измените набор слияний.

Ответ 3

Вы можете использовать опцию --rev hg stat с парой ревизий, чтобы увидеть, какие различия между файлами существуют между ними. Ниже приведен немного подробный, но подробный пример:

Сначала мы начинаем с создания нового репозитория:

[gkeramidas /tmp]$ hg init foo
[gkeramidas /tmp]$ cd foo

Затем добавьте один файл с именем foo.txt в новый репозиторий:

[gkeramidas /tmp/foo]$ echo foo > foo.txt
[gkeramidas /tmp/foo]$ hg commit -Am 'add foo'
adding foo.txt
[gkeramidas /tmp/foo]$ hg glog
@  0[tip]   b7ac7bd864b7   2011-01-30 18:11 -0800   gkeramidas
     add foo

Теперь добавьте второй файл под названием bar.txt в качестве версии 1:

[gkeramidas /tmp/foo]$ echo bar > bar.txt
[gkeramidas /tmp/foo]$ hg commit -Am 'add bar'
adding bar.txt

Вернитесь к ревизии 0 и добавьте третий файл в другую голову. Это делается для моделирования притяжения от кого-то, кто клонировал тот же репозиторий при его начальной версии:

[gkeramidas /tmp/foo]$ hg up -C 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
[gkeramidas /tmp/foo]$ echo koko > koko.txt
[gkeramidas /tmp/foo]$ hg commit -Am 'add koko'
adding koko.txt
created new head
[gkeramidas /tmp/foo]$ hg glog
@  2[tip]:0   e5d80abdcb06   2011-01-30 18:12 -0800   gkeramidas
|    add koko
|
| o  1   a2d0d0e66ce4   2011-01-30 18:12 -0800   gkeramidas
|/     add bar
|
o  0   b7ac7bd864b7   2011-01-30 18:11 -0800   gkeramidas
     add foo

Теперь вы можете использовать hg stat, чтобы узнать, какие различия в файлах существуют между любой парой ревизий, например. изменения от rev 0 до rev 1 добавили "bar.txt" в список файлов:

[gkeramidas /tmp/foo]$ hg stat --rev 0:1
A bar.txt

Изменения от rev 0 до rev2 добавили "koko.txt" в список файлов:

[gkeramidas /tmp/foo]$ hg stat --rev 0:2
A koko.txt

Но более интересно, изменения от rev 1 до rev 2 включают в себя два изменения манифеста файла. (1) 'koko.txt' был добавлен в rev 2, а (2) "bar.txt" существует в rev 1, но отсутствует в rev 2, поэтому он отображается как "удаленный" файл:

[gkeramidas /tmp/foo]$ hg stat --rev 1:2
A koko.txt
R bar.txt