Lost changes during merges

[Mads Kiilerich]

Pavel Shevaev wrote, On 01/20/2010 12:47 PM:
>> Now you are redoing 7719:f4692a47d6bd. Was there a problem there too?
>>      
> No there was no problem I just wanted to trace all his merges.
>    

That is a good idea. But I suggest that once you have confirmed that 
this merge was OK that you then throw your own merge away - either by 
"up -C" instead of committing or by stripping or creating a new clone.

>> I thought the problem was 7722:180b55133042?
>>      
> That's right problem happened in this revision.
>
> I tried to clone the repo to get exactly to the problem as you
> suggested(hg clone -r 7721 -r 7684 repo): I got the conflict during
> the merge and I could clearly see my changes. Then I tried the earlier
> revisions/merges and pulled in my changes(as described in my previous
> email) but they all worked fine as well.
>    

If you are sure you have redone 7722:180b55133042 correctly from both 
points of view then commit it with a description "The merge from 
180b55133042 done right".

Then create a dummy merge between your good merge and the bad one, and 
make sure that the result of that merge is exactly the same as your good 
merge. Commit that with a description "Hide bad merge in 180b55133042".

When you merge the new perfect dummy merge with your existing "branch 
heads" then the lost changes should be reintroduced.

I suggest you create a new clone and practice a couple of times before 
doing it for real and pushing the result to your main repo.

(BTW: Be careful when using the revision numbers in text and examples. 
They are easy to comprehend but requires a specific repository as 
context and are not stable between clones, and that can easily cause 
confusion. Use (a part of) the hash instead.)

/Mads