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

Question

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

Answer 1

hg resolve --list

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

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

Изменить 5 января 2012 года:

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

Вопрос в том, что «я выполнил извлечение данных из удаленного репозитория, а еще не выполнил слияние. Могу ли я увидеть, какие конфликты возникнут при выполнении слияния?»

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

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

На этом этапеВы можете сделать 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.

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

Answer 2

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

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

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

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

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

Answer 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 , чтобы увидеть, какие различия в файлах существуют между любой парой ревизий, например, изменения с версии 0 до версии 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

Но что более интересно, изменения от версии 1 до версии 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

Answer 4

Я думаю, hg status - это то, что вы ищете.

Вы можете прочитать эту главу в Mercurial: Полное руководство

http://hgbook.red -bean.com/read/mercurial-in-daily-use.html