hg merge preview

[Peter Toft]

On Wed, 31 Aug 2011 17:17:08 +0200, Christian Ebert wrote: 

> *
Martin Geisler on Wednesday, August 31, 2011 at 15:06:28 +0200
>> Not
really -- to identify the problems you will have to run (simulate) the
merge process. So the best you can do is to do it non-interactively and
then revert back to where you were. Start the merge with: $ hg merge
--tool internal:merge List the status of the merge: $ hg resolve --list
Abort the merge with: $ hg update -C . You can wrap all this into a
shell alias: [alias] preview = !$HG -q merge --tool internal:merge &&
$HG resolve --list && $HG -q update -C .
> Nice, but it should be:
preview = !$HG -q merge --tool internal:merge ; $HG resolve --list &&
$HG -q update -C . Otherwise it aborts after the merge. c

Super nice!
Thanx to Christian to the fix - and to Martin for the idea (mange tak -
Danish). 

This is a very handy detection of problems we get here. 

Can
you see a "simple" way of identifying the other relevant files in this
example (B.txt and C.txt): 

User A: 

 echo " " >> A.txt 

 echo " " >>
B.txt 

 hg commit -m "bla from A" 

 hg push 

User B: 

 echo "x" >>
A.txt 

 echo " " >> C.txt 

 hg commit -m "bla bla from b" 

 hg pull


Now user B can use "hg preview `hg heads | head -n 1 | grep changeset
| cut -d: -f 2`" to get the problematic merge-conflict A.txt found, but
what about the B.txt and C.txt which differ in the two heads - albeit
they can merge clean. 

Ideas? :) 

-- 
Peter Toft,
PhD
http://petertoft.dk
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20110831/2ea84423/attachment-0002.html>