Mercurial - voir la liste des fichiers qui doivent être fusionnés manuellement?

hg resolve --list

De la la documentation:

Fusionne avec les conflits non résolus sont souvent le résultat de la non-interactive de fusion à l'aide de l'interne:la fusion des paramètre de configuration, ou une ligne de commande outil de fusion comme diff3. La détermination de commande est utilisé pour gérer les fichiers impliqués dans une opération de fusion, après hg merge a été exécuté, et avant de hg commit est exécuté (c'est à dire le répertoire de travail doit avoir deux parents).

Modifier 5 Janvier 2012:

(J'ai reçu un vote pour cette réponse aujourd'hui, j'ai donc revu. J'ai découvert que j'ai mal compris la question.)

La question est: "j'ai effectué un pull à partir d'un dépôt distant et n'ont pas encore effectué une fusion. Puis-je voir ce que les conflits seront créés lors de l'exécution de la fusion?"

Ma réponse ci-dessus est clairement erroné. Après la lecture par le biais liés à la documentation, je ne pense pas qu'il y est une méthode intégrée pour le faire. Cependant, il y a un moyen de le faire sans ruiner votre arbre des sources.

Supposons que vous avez cloné référentiel Un à partir d'une certaine distance de la source au dépôt B sur votre système local, c'est à dire hg clone http://hg.example.com/A B. Après cela, vous apportez des modifications à votre dépôt local, B, qui impliquent au moins un commit. Dans l'intervalle, des modifications ont été apportées au référentiel Un de sorte que lorsque vous faites une traction, vous obtenez un message indiquait nouvelles révisions ont été ajoutés et les têtes ont été créés.

À ce stade, vous pouvez faire hg heads de la liste les deux révisions qui seront impliqués dans un processus de fusion. À partir de cette information, vous pouvez émettre une commande d'état d'énumérer les différences entre les chefs. En supposant que le numéro de révision du référentiel B, selon les têtes de liste, sont des "1" et "2", alors vous pouvez faire hg status --rev 1:2 pour voir une liste des modifications.

Bien sûr, ce n'est pas vraiment vous dire si les conflits se produire lorsque vous effectuez une opération de fusion. Puisqu'il n'y a pas une commande qui va vous montrer cela, vous aurez à "aperçu" de la fusion par clonage d'un nouveau référentiel et faire la fusion de là. Donc, hg clone B C && cd C && hg merge. Si vous êtes satisfait avec le résultat de cette fusion que vous pouvez faire hg com -m 'Merging complete' && hg push && cd ../&& rm -rf C.

C'est un peu le processus, mais il maintient votre source de courant arbre propre si la fusion s'avère être un désastre. Vous pouvez également trouver des cette description de travail avec les dépôts publics utile.

Vous pouvez utiliser le --rev option de hg stat avec une paire de révisions pour voir ce fichier existe des différences entre les deux. Voir ci-dessous pour un peu verbeux mais exemple détaillé:

Nous avons d'abord commencer par faire un nouveau référentiel:

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

Puis ajouter un fichier unique appelé foo.txt pour le nouveau référentiel:

[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

Maintenant ajouter un second fichier, appelé bar.txt que de la révision 1:

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

Revenir à la révision 0, et ajouter un troisième fichier, sur un autre tête. Ceci est fait pour simuler une pull de quelqu'un d'autre qui avait cloné le même référentiel, à son départ de révision:

[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

Maintenant, vous pouvez utiliser hg stat pour voir ce fichier existe des différences entre les paires de révisions, par exemple, les changements de rev 0 rev 1 ajoutée "bar.txt" pour la liste des fichiers:

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

Les changements de rev 0 à rev2 ajoutée "koko.txt" pour la liste des fichiers:

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

Mais plus intéressant encore, les changements de rev 1 rev 2 impliquent deux fichier manifeste des changements. (1) 'koko.txt" a été ajouté dans la version 2, et (2) 'bar.txt" existe dans la version 1, mais manquant de rev 2, de sorte qu'il s'affiche comme un "enlevé" fichier:

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